W3C home > Mailing lists > Public > public-html@w3.org > July 2015

Re: Allowing nested <time> elements.

From: Martin Janecke <w3.org@prlbr.com>
Date: Sat, 4 Jul 2015 11:28:39 +0200
To: public-html@w3.org
Message-ID: <5597A747.6030403@prlbr.com>
On 03.07.15 20:07, Marat Tanalin wrote:
> If I understand correctly, WHATWG Wiki proposes a different thing: a DRY way to markup date without need to duplicate its components both as `TIME`-element contents and in its `datetime` attribute.
>
> Elaborating the WHATWG idea, I would like to have _dedicated elements_ for date components, e.g. for year, month and day in particular:
>
>      <time>
>          <day>30</day>.<month>05</month>.<year>1980</year>
>      </time>
>
> So we could markup dates DRY way, without need to duplicate date components in the `datetime` attribute just because their order inside the `TIME` element is different from the machine-readable one defined in the spec while each component itself _is_ machine-readable. This is in line with what WHATWG wiki proposes, just even better -- with pure clean HTML semantics instead of microformats or clumsy multiple nested `TIME` elements with attributes.
>
> In the example above, the date is in Russian date format, and we are currently forced to specify date components _twice_ -- both as contents of the `TIME` element _and_ in its `datetime` attribute:
>
>      <time datetime="1980-05-30">
>          30.05.1980
>      </time>
>
> Dedicated elements for hours, minutes and seconds would probably also be useful.

What about week and timezone?

In my opinion, this is getting out of hand. In following the DRY 
principle like this we would introduce a family of new elements, which 
would bloat the specification and the software that is interpreting 
these dates/times; we could even bloat webpages: note that despite DRY 
your first example is longer than the example for the current state.

I'd rather adhere to the KISS principle here. The time element is useful 
if its syntax is very clear, uncomplicated, easily machine readable. 
Fine machine readability is what this element is for.


> Another issue of the current `TIME` spec is that "time element that does not have a datetime content attribute must not have any element descendants" (it's interesting though that both validator.nu and validator.w3.org treat `TIME` elements without `datetime` attributes and with elements descendants as _valid_). So if we need to style some of components separately (and thus wrap it in a container like `SPAN`), the `TIME` element contents are not (as per spec) treated as a time even if its text content _is_ in machine readable form:
>
>      <time>1980-05-<span>30</span></time>
>
> So we are forced to also add datetime attribute that contains text identical to (already provided) text content of the element:
>
>      <time datetime="1980-05-30">1980-05-<span>30</span></time>
>
> This looks like a harmful limitation.

Everything that makes reading it more complex for machines weakens the 
element in my opinion, i.e. nesting, more element names, alternative 
datetime syntax options, element descendents when there's no datetime 
attribute etc. I can understand all these suggestions from an author's 
point of view, but they all seem to forget what the purpose of the time 
element is.

Martin
Received on Saturday, 4 July 2015 09:29:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:44 UTC