Re: Allowing nested <time> elements.

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


Countering that, one could argue that if all the dates define within <time
datetime="2015"> are indeed dates for the year 2015 then it is a year, or
the entire contents make-up the year. Similarly, every day within <time
datetime="2015-07"> defines the contents of July of that year and the
contents of <time datetime="2015-W27">  define the contents of that week in
2015.

I am not looking to add anything extra to the specification, just to remove
an apparent constraint that actually isn't within the specification at the
moment.

Why is the constraint not mentioned in the specification? (or perhaps it
is, and I simply missed it on my numerous readings)
Why was it added?
Is it still relevant?

I'd really like to hear from those who defined it.

======================================
Ian Devlin
iandevlin.com <http://www.iandevlin.com>
@iandevlin <http://www.twitter.com/iandevlin>
skype: idevlin
======================================

On 3 July 2015 at 20:07, Marat Tanalin <mtanalin@yandex.ru> wrote:

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