Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.My proposal is to add a number of new theme functions, or re-purpose/reuse existing functions, in order to bring consistency (as much as we can) to Drupal core output across modules and templates.
Drupal already does a really good job of this, however there are some places we can improve, so this is really a meta issues for throwing up discussion/ideas and then create specific issues that stem out of the ensuing debate. I've tagged this as HTML5 because this really stemmed from my prototyping for HTML5 in D8 core, although of it is not specific to HTML5.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | theme_datetime.patch | 1.23 KB | Everett Zufelt |
Comments
Comment #1
Jeff Burnz CreditAttribution: Jeff Burnz commentedThe first one that really strikes me is our formatting of dates and times.
Our current use of times and dates is rather inconsistent in core, for example lets compare just a couple:
Node:
$variables['date'] = format_date($node->created);Eventually this is printed in node tpl via $submitted and no markup is added anywhere - its naked and unless RDFa is enabled this carries zero semantics.
Aggregator:
$variables['feed_age'] = t('%age old', array('%age' => format_interval(REQUEST_TIME - $item->timestamp)));$feed_ageis printed in aggregator-summary-item.tpl.php wrapped in span's with a class:<span class="age"><?php print $feed_age; ?></span>There are quite a few other instances of this sort of inconstancy in aggregator, and of course comment tpl does essentially the same thing as node.
I think we have a use case here for a
theme_datetime()function. This would provide a simple wrapper with attributes. This will allow much easier global override of markup for dates and times, for example if we want to use XHTML we can use a span, if we want to use HTML5 we can use time + the time attributes such as pubdate, datetime etc.In HTML5 we can use the
<time>element. Here's a bit of a write up about it and if you're really hard core read the spec.Note that we already have a
theme_datewhich is used to returns HTML for a date selection form element, so that namespace is taken.Comment #2
Everett Zufelt CreditAttribution: Everett Zufelt commented@Jeff
What are your ideas around the types of attributes that would be passed to theme_datetime()?
My thoughts would be that we pass in a unix timestamp We also need to be able to pass in at least a boolean value for pubdate, but might optionally allow a date formate type (including custom) to be passed in.
This would be sufficient to do html5 time elements
if ($pubdate) {
$element['attributes']['pubdate'] = 'pubdate';
}
$datetime = format_date($timestamp, 'custom', 'y-m-d h:i');
$element['attributes']['datetime'] = $datetime;
$datetime_content = format_ate($timestamp, $format_type, $format_custom);
This clearly gets more difficult with localization and timezones, but since the code is already in core to do this it can just be abstracted into the theme_datetime() function.
Comment #3
Everett Zufelt CreditAttribution: Everett Zufelt commentedAs a starting point. Likely should be spinned off into to its own issue.
Comment #4
Everett Zufelt CreditAttribution: Everett Zufelt commentedSee #1183250: Add a theme_datetime() function to consistently theme dates and datetimes
Comment #5
JacineCan we close this? We already have an issue for the date stuff, and that's really the only solid idea brought forth in here. I completely agree that we'll need to add more theme functions, but I think we'll be better off creating issues for them as we think of them. Let me know what you think.
Comment #6
Jeff Burnz CreditAttribution: Jeff Burnz commentedYep, closed in favor of #1183250: Add a theme_datetime() function to consistently theme dates and datetimes and any new issues.