[whatwg] <time> parsing and rendering

[Philip Jägenstedt]

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-month-component

Is there a use case for machine-readable dates after 9999? I'm sure HTML5  
will have been obsoleted before it's meaningful to express accurate times  
that far in the future. As existing similar formats use a 4-digit year,  
adapting parsers for those is a lot easier if the HTML5 year format be  
exactly 4 figures. Also, it seems more likely that >4-digit years will be  
typos than intended and useful as machine-readable data. If there are no  
strong use cases for it, please make it YYYY only.


http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-date-or-time-string	

"10. If the date present and time present flags are both true, but  
position is beyond the end of input, then fail."

This seems to be a bug if you consider how '2009-11-16T' would be parsed.  
The algorithm is supposed to return a date time or global date and time,  
but '2009-11-16T' is valid as neither. The intent of this step must be to  
make sure that T is always followed by a date, but it won't work. Except  
 from being in the incorrect order (after time present may have been set to  
false) it also checks for the end of input, which doesn't make sense when  
the "in content" variant is used.

Perhaps it would be possible to simply replace this algorithm with "try  
parsing a global date and time, else try parsing a date, else try parsing  
a time"? I haven't check carefully if this is equivalent though.


http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-time-element-0

"When the time binding applies to a time element, the element is expected  
to render as if it contained text conveying the date (if known), time (if  
known), and time-zone offset (if known) represented by the element, in the  
fashion most convenient for the user."

This is very vague. Anything which tries to localize the date/time will  
fail because guessing the language of web pages is hard. Hard-coding it to  
English also wouldn't be very nice. What seems to make the most sense is  
using the "best representation of the global date and time string" and  
equivalents for just time and date that have to be defined. Still, I'm not  
sure this is very useful, as the same rendering (but slightly more  
flexible) could be accomplished by simply putting the date/time in the  
content instead of in the attribute. As a bonus, that would degrade  
gracefully. Unless I'm missing something, I suggest dropping the special  
rendering requirements for <time> completely.

-- 
Philip Jägenstedt
Opera Software