Opened 10 years ago
Closed 5 years 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)
Change History (17)
#4
@
9 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
@
6 years ago
I don't think this can or should be handled by a filter, that would introduce a myriad of problems, such as:
- Any call that explicitly provides date format will be broken by it.
- Any call that goes through escaping before output will be broken by it.
- 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.
#7
follow-up:
↓ 10
@
5 years 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
This ticket was mentioned in Slack in #core-datetime by rarst. View the logs.
5 years ago
#9
@
5 years ago
- Milestone changed from Awaiting Review to 5.3
- Owner set to SergeyBiryukov
- Status changed from new to reviewing
#10
in reply to:
↑ 7
@
5 years 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
@
5 years 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.
#12
@
5 years 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.
#14
@
5 years 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
@
5 years 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.
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.