Re: Allowing nested <time> elements.

On 05.07.15 17:53, Marat Tanalin wrote:
> […]
>
> 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.

The element as it is now is a reality. Describing it is a necessity. 
Adding an alternative syntax isn't.


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

Which use cases do you see for your proposal of dedicated elements that 
the current time element does not solve?


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

In the first place, we don't need markup to write a date or time in an 
HTML document. <time> has been introduced explicitly to annotate the 
human readable date/time with a machine readable version.^[1]

The good readability for machines is in order to provide a better 
experience to humans in the end. For example, it helps developers write 
software that translates dates and times into a format that the reader 
chooses.

But good readability for machines and clarity for humans are not 
necessarily in conflict. I as a human am comfortable with the datetime 
syntax.

Martin

___
#[1] “The time element represents its contents, along with a 
machine-readable form of those contents in the datetime attribute. The 
kind of content is limited to various kinds of dates, times, time-zone 
offsets, and durations, as described below.” 
(http://www.w3.org/TR/html/text-level-semantics.html#the-time-element)

Received on Sunday, 5 July 2015 22:45:02 UTC