Re: Allowing nested <time> elements.

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:

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

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.

Received on Friday, 3 July 2015 18:07:43 UTC