WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 11 months ago

#29325 closed enhancement (maybelater)

Use <time datetime> tag in Post Date

Reported by: Apiweb Owned by: SergeyBiryukov
Milestone: Priority: normal
Severity: normal Version:
Component: Date/Time Keywords: has-patch
Focuses: Cc:

Description

I think it would be interesting to use the tag <time datetime> in the dates, that WordPress uses (and extends it to the plugins).
For some this tag may be useless, but it has its value (besides not add anything visually), as interpreted by the machine, its use could be varied:

A browser could offer to add events to a user’s calendar. A Thai-localised browser could offer to transform Gregorian dates into Thai Buddhist era dates. A Japanese browser could localise <time>16:00</time> to “16:00時”. Content aggregators can produce visual timelines of events.

Some links for this tag:
W3.org
W3School
Mozilla Developer Network
HTML5 Doctor

Attachments (2)

29325.diff (1.5 KB) - added by diddledan 5 years ago.
add new function to include <time> tags if the theme declares support
the-time-tag.patch (1.2 KB) - added by Rarst 12 months ago.

Download all attachments as: .zip

Change History (17)

#1 @SergeyBiryukov
6 years ago

  • Component changed from General to Date/Time

#2 @chriscct7
5 years ago

  • Keywords needs-patch added

#3 @diddledan
5 years ago

I'd like to have a crack at tackling this as "my first bug", but I'm wondering if anyone has thoughts as to preventing conflicts with themes that add the tag themselves?

So far, I've thought about adding a filter which a theme could choose to unhook, but that would still cause breakage if a theme, which applies <time> itself, is left unchanged when the new code lands into core.

@diddledan
5 years ago

add new function to include <time> tags if the theme declares support

#4 @diddledan
5 years ago

  • Keywords has-patch added; needs-patch removed

The attached patch adds a new function hooked into the_date filter. This function will add <time datetime=""></time> tags if the active theme specifies that it supports this. Adding theme support is via html5/time-tag:

add_theme_support( 'html5', array( 'time-tag', ... ) );

#5 @Rarst
2 years ago

I don't think this can or should be handled by a filter, that would introduce a myriad of problems, such as:

  1. Any call that explicitly provides date format will be broken by it.
  2. Any call that goes through escaping before output will be broken by it.
  3. Even if theme explicitly opts in for it, there is no guarantee that any and all plugins running can handle it.

I am in favor of <time> tag being used in practice, but adding it to existing API is simply not viable.

We could consider a new dedicated function for it though.

#6 @Rarst
2 years ago

  • Keywords needs-patch added; has-patch removed

#7 follow-up: @Rarst
12 months ago

  • Keywords has-patch added; needs-patch removed

Added a small the_time_tag() function, defaulting to post published time but accepting arbitrary time stamp. Didn't want to go too crazy with flexibility, if someone needs to mess with it a lot they should probably just write their own tag logic.

Needs wp_date() merged #28636

Last edited 12 months ago by Rarst (previous) (diff)

This ticket was mentioned in Slack in #core-datetime by rarst. View the logs.


12 months ago

#9 @SergeyBiryukov
12 months ago

  • Milestone changed from Awaiting Review to 5.3
  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#10 in reply to: ↑ 7 @SergeyBiryukov
12 months ago

Replying to Rarst:

Added a small the_time_tag() function, defaulting to post published time but accepting arbitrary time stamp.

Thanks for the patch! If the_time_tag() is intended for posts, it seems weird that it doesn't accept a $post parameter, like get_the_date(), get_the_time(), etc.

function the_time_tag( $format = '', $timestamp = null ) {
function get_the_date( $d = '', $post = null ) {
function get_the_modified_date( $d = '', $post = null ) {
function get_the_time( $d = '', $post = null ) {
function get_the_modified_time( $d = '', $post = null ) {
function get_post_time( $d = 'U', $gmt = false, $post = null, $translate = false ) {
function get_post_modified_time( $d = 'U', $gmt = false, $post = null, $translate = false ) {

Would it make more sense to pass $post as a second parameter, instead of $timestamp, for consistency with the other functions?

If it's intended as a general purpose function, then I think it should be just that, and something like the_post_time_tag() could wrap it to display a post time.

#11 @Rarst
12 months ago

get_ retrieval functions typically allow changing post context, the_ template tags typically don't and are just meant for the loop.

I considered implementing get_ "level" for this one, but since it returns HTML markup, I didn't want to encourage passing that around.

I think making it general purpose function makes it a little too hard to use as a "just works" template tag, so maybe two different functions does make sense.

If it works out too clunky we could drop it too. This one isn't mission-critical.

Last edited 12 months ago by Rarst (previous) (diff)

#12 @diddledan
12 months ago

We do have precedent here: https://developer.wordpress.org/reference/functions/get_the_post_thumbnail/

The get_the_post_thumbnail returns HTML so it is not unexpected that other get_* functions can do the same IMO.

#13 @diddledan
12 months ago

argh, branfart *deleted my post*

Last edited 12 months ago by diddledan (previous) (diff)

#14 @Rarst
12 months ago

There is a lot of precedent in WP core for things that are generally not a good idea. :)

Looking at spec for the tag the generic helper would be... non-trivial. The thing supports not just times, but date-only, time-only, and duration string values. At which point we are busy building a complex PHP abstraction for a single HTML tag instead of just templating it.

Let's step back and consider this question — where in WP core or theme development do we need this implemented as dedicated function as opposed to templating this output?

I might be wrong, but it is my impression that value of this tag is in cases where it's used for specific purpose (such as specific script working with markup meant for it) rather than generically.

#15 @Rarst
11 months ago

  • Milestone 5.3 deleted
  • Resolution set to maybelater
  • Status changed from reviewing to closed

I think I am shelving this for now. It really is a non-trivial tag to implement generically, it's easy to template with existing API, and there is no outstanding functionality that needs a dedicated function for this.

Note: See TracTickets for help on using tickets.