[whatwg] <time> element feedback

[Martin Janecke]

Am 31.08.10 02:35, schrieb Ian Hickson:
 > On Sat, 7 Aug 2010, Tantek Çelik wrote:
 >>
 >> the new<time>  element is very useful for absolute dates and times,
 >> but omits several useful granularity levels, in particular for dates.
 >>
 >> The following additional date granularities would be useful, and are
 >> fairly straightforward to incorporate into the spec (and
 >> implementations):
 >>
 >> * year only: YYYY
 >> * year-month only:  YYYY-MM (also corresponds to output form of input
 >> type=month)
 >> * year-week only: YYYY-WNN (also corresponds to output form of input
 >> type=week)
 >> * month-day only: --MM-DD (common birthdays without year use case)
 >>
 >> http://wiki.whatwg.org/wiki/Time#Date_granularity
 >
 > As far as I can tell, none of these are use cases
 > for<time>YEAR</time>, as opposed to just YEAR. (But it's hard to
 > tell, because the wiki page is very brief and doesn't even use full
 > sentences.)

I disagree.

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

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


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


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