Re: Allowing nested <time> elements.

04.07.2015, 12:31, "Martin Janecke" <w3.org@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:
>
> What about week and timezone?

I would probably use dedicated element names (e.g. straightforward `WEEK` and `TIMEZONE`) for them as well if someone needs them. `TIME` looks mainly like a time _moment_. Using the same `TIME` element for quite different things like durations (with moving semantics from element/attribute names to _text_ format of their _contents_ instead of using dedicated elements like `DURATION`) was probably a design mistake breaking the roots of HTML.

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

Bloat looks like just a buzzword to reject features with no reason.

To the same extent, using a single element name with multiple allowed (and needed to parse) data formats "bloats" the spec and implementations compared with dedicated elements -- each for its own purpose and with just one clear allowed data format.

Element is the main semantic unit of HTML, there is nothing wrong in extending set of HTML elements for different things as needed.

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

Unlike XML, HTML is in large part to write code by hand. So main goal in HTML design should probably be clarity and ease of use for _people_ in the first place.

Received on Sunday, 5 July 2015 15:53:50 UTC