[whatwg] <time> element feedback

[Ian Hickson]

On Tue, 31 Aug 2010, Martin Janecke wrote:
> 
> (1) There's the example of relative date phrases that refer to an absolute
> date. For example:
> <time datetime='2009'>Last year</time>'s temperature was above average.

What's the use case here? What problem is this solving that isn't solved 
by just writing this?:

   <span title="2009">Last year</span>'s temperature was above average.

Before we add features to HTML, we follow the steps described here:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

I am not aware of any use cases or problems here (steps 1 and 2).


> (2) There's the example of dates written in a local format that is not 
> widely understood anywhere else in the world. For example:
>
> <time datetime='2010'>平22年</time> saw no major earthquakes in Japan. 
>
> Besides, <time>2010</time> in a British news article would allow users 
> e.g. in Japan to have these dates displayed as 平22年. That's clearly 
> an advantage over the number 2010 alone. Most examples given in the Wiki 
> are use cases for this. Of course not only Japanese would profit but 
> anyone who uses a different calendar from the Gregorian one.

This specific use case I agree has merit; as I've said before, though, we 
should wait to see if the similar features already in the spec gain 
traction with implementors and authors before adding yet more features 
here. The danger otherwise is that we overload implementors with too many 
new features, and they don't support any of them.


> > On Mon, 9 Aug 2010, Tantek Çelik wrote:
> >>
> >> HTML5 provides mechanisms for both semantically inputting datetime 
> >> values (via the 6 new datetime<input> types), and semantically 
> >> outputting datetime values (via the new<time> element). However, the 
> >> types/granularities of dates and times that are supported do not 
> >> match up on input vs output, and they should.
> >
> > Why?
> >
> >
> >> From a design, learning/teaching perspective, it is much better if 
> >> they are made to match up, that is if every type/granularity of 
> >> datetime that can be entered can also be semantically marked up (and 
> >> vice versa).
> >
> > Why?
> 
> This would be intuitive – at least to me – and I assume to others as 
> well. It's less complicated if there are less differences, it's less to 
> keep in mind.
> 
> Supporting different date formats for both will most likely lead to more 
> incorrect usage than in case of matching date format support.

I think one can argue similarly that things are less complicated when 
there are fewer features. I'm not sure that either is more compelling than 
the other. Given that we can complete the pattern once we have 
implementation experience, though, that seems like the best bet on the 
short term.


> >> It would also be nice to have a year state for<input>, as it has more 
> >> use cases than week, and it would allow combining with the month 
> >> state for e.g. credit card info.
> >
> > Can you show me a page that has a special control for year input, 
> > rather than just a regular text input?
> 
> Here are results of a quick research:
> 
> The Bank of Canada (<select>)
> http://www.bankofcanada.ca/en/rates/exchform.html
> (I am aware that this usage would not be replaced by a year only input, still
> it shows that not all people think text-only suits best for year input.)
> 
> Japanese year converter (<select>)
> http://www.allcalendars.net/JapaneseYearConverter.php
> 
> Kitco charts (<select>, <input type="checkbox">)
> http://www.kitco.com/charts/historicalgold.html
> Especially note the YEARLY GOLD CHARTS section.

It seems to me that HTML already satisfies their use cases completely 
here, without needing any new features. This is in contrast to date 
pickers, where authors have frequently found that HTML does _not_ satisfy 
their use cases, to the point of them using JS libraries to have custom 
date pickers.


On Tue, 31 Aug 2010, Martin Janecke wrote:
> 
> I understand that it's not good to implement features that won't be used 
> by anyone in the end. Nevertheless I am worried that this could lead to 
> a chicken or the egg dilemma, i.e. HTML waits for CSS to implement 
> styling (year-only) dates and CSS waits for HTML implementing 
> year-only-dates before making them stylable?

HTML isn't waiting for CSS to make the first move -- HTML has already gone 
a step beyond what CSS supports here. Now we have to make sure we also 
support this in CSS, before adding even more to HTML. Generally when 
technologies work together like this they leap-frog each other, roughly in 
sync with implementations. This ensures that the whole platform doesn't 
ever get too far ahead of implementations, and it ensure that we don't go 
too far into the weeds with a bad idea before stopping.


The remainder of this thread discussed the pros and cons of having <time> 
localise times. This issue will be decided by the market one way or the 
other; it's not clear to me that we can make progress on it here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'