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

Re: Allowing nested <time> elements.

From: Marat Tanalin <mtanalin@yandex.ru>
Date: Fri, 03 Jul 2015 21:07:10 +0300
To: Ian Devlin <ian.devlin@gmail.com>, "public-html@w3.org" <public-html@w3.org>
Message-Id: <1879771435946830@web6j.yandex.ru>
03.07.2015, 15:32, "Ian Devlin" <ian.devlin@gmail.com>:
> If nested <time> elements were allowed, it would then be possible to define more semantic HTML calendars such as:
> ...
> The WHATWG Wiki also recommends allowing nested time elements (https://wiki.whatwg.org/wiki/Time_element#composite_nested_time_elements), listing other benefits.

I'm not sure it would have much semantic sense to markup the whole calendar as a single `TIME` element with nested `TIME` elements as you propose.

"1 2 3 ... 30 31" (text content from your example) is not a year (these are days), nor is "2015-07" (datetime equivalent content from your example) a year (it's a month).

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:


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">

Dedicated elements for hours, minutes and seconds would probably also be useful.

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:


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.
Received on Friday, 3 July 2015 18:07:43 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:14 UTC