[whatwg] <time> element feedback

Mon Aug 30 17:35:52 PDT 2010

On Sat, 7 Aug 2010, Tantek Ã~Gelik 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.)

On Mon, 9 Aug 2010, Tantek Ã~Gelik 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?

> It would be great if you could add your +1 accordingly to allowing 
> <time> to markup just a year:
> http://wiki.whatwg.org/wiki/Time#year_only

Note that I completely ignore volume of feedback and only look at the 
actual arguments presented. +1s and -1s have no effect on the spec.

On Tue, 10 Aug 2010, Tantek Ã~Gelik wrote:
>
> We know from experience with past methods of duplicated invisible 
> (meta)data, and more recently, development/use/experience with visible 
> microformats, that when we are able to re-use the visible data, 
> published *once*, by humans for humans, we get more accurate data over 
> time, than when we have at times asked for *duplicating* the data in a 
> different (more machine readable) format (or location).  This experience 
> yielded the microformats adoption of the DRY principle - don't repeat 
> yourself - in application to (meta)dataformat designs and techniques.
> 
> The <time> element currently encourages DRY violations in most of its
> use cases (duplication of datetime information inside the 'datetime'
> attribute in addition to the visible content of the element).

You don't have to give content in the element. In fact it's basically only 
allowed for fallback for legacy UAs.

> 1. composite nested time elements.
> 
> In short, instead of this (actual example derived from markup of blog
> post HTML5 watch[1] by Jeremy Keith)
> 
> <time class="published" datetime="2009-12-13T17:43:29">
>   Sunday, December 13th, 2009
>   5:43pm
> </time>
> 
> We want to be able to do this:
> 
> <time class="published">
>   <time datetime="2009-12-13">Sunday, December 13th, 2009</time>
>   <time datetime="17:43:29">5:43pm</time>
> </time>
>
> and have the parent <time> element composite a complete datetime from 
> the child <time> elements with separate date and time.

There's just as much hidden metadata and a ton more markup. That seems 
like a loss to me.

Why not just do:

  <time pubdate datetime="2009-12-13T17:43:29Z"></time>

...which means the same thing and has no hidden metadata? (Modulo timezone 
issues; note that floating datetimes aren't allowed with <time> currently.)

> 2. am pm and coarser time parsing
> 
> Summary: by permitting am pm and coarser time values, many more
> instances of time markup can be minimized to in-content only (not
> requiring a datetime attribute) and thus reduce many DRY violations.
> 
> In short, instead of this (actual example derived from markup of blog
> post HTML5 watch by Jeremy Keith, with nested time elements per
> previous proposal)
> 
> <time class="published">
>   <time datetime="2009-12-13">Sunday, December 13th, 2009</time>
>   <time datetime="17:43:29">5:43pm</time>
> </time>
> 
> We want to be able to do this:
> 
> <time class="published">
>   <time datetime="2009-12-13">Sunday, December 13th, 2009</time>
>   <time>5:43pm</time>
> </time>
> 
> It's a minor DRY improvement (time info is no longer duplicated), but 
> one that we think is worth it across the numerous pieces of content 
> authored as such and the resulting increased accuracy from DRY 
> reduction.
> 
> This type of am pm parsing as spec'd in the Value Class Pattern has been 
> interoperably implemented and shipped (Operator, X2V).  Thus we think it 
> is reasonable to add this similar feature to HTML5.

Again, just use a single <time> with no content and put all the data in 
the datetime="" attribute.

On Wed, 11 Aug 2010, Tantek Ã~Gelik wrote:
>
> The first markup example in section 4.6.9 needs updating:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element
> 
> Current Example and text:
> =========================== snip ===========================
> <div class="vevent">
>  <a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
>   <span class="summary">Web 2.0 Conference</span>:
>   <time class="dtstart" datetime="2007-10-05">October 5</time> -
>   <time class="dtend" datetime="2007-10-20">19</time>,
>   at the <span class="location">Argent Hotel, San Francisco, CA</span>
>  </div>
> 
> (The end date is encoded as one day after the last date of the event
> because in the iCalendar format, end dates are exclusive, not
> inclusive.)
> =========================== snip ===========================
> 
> Suggested update:
> =========================== snip ===========================
> <div class="vevent">
>  <a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
>  <span class="summary">Web 2.0 Conference</span>:
>  <time class="dtstart" datetime="2005-10-05">October 5</time>-
>  <time class="dtend" datetime="2005-10-07">7</time>,
>  at the <span class="location">Argent Hotel, San Francisco, CA</span>
> </div>
> =========================== snip ===========================
> 
> Note: the parenthetical paragraph in the previous version about end date 
> inconsistency has been removed since hCalendar 1.0 has resolved that 
> issue (see dtend issue for details).

It's unclear to me what is being fixed here. Can you elaborate?

On Fri, 20 Aug 2010, Oli Studholme wrote:
> On Thu, Mar 19, 2009 at 10:35 AM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > The primary use cases for <time> are:
> >
> > * The ability to encode 80% of dates and times in a machine-readable 
> > way so that the user can make use of them in an automated fashion, in 
> > particular for adding dates to a calendar.
> >
> > * The ability to restyle dates that contain a "day" component so that 
> > they follow user conventions (2000-12-31 vs 31-12-2000 vs 12-31-2000).
> >
> > * The ability to encode the output of <input type=date> and <input 
> > type=time> in an unambiguous fashion, for styling.
> >
> > None of these require that <time> be able to express years or 
> > year-month pairs; what are the use cases that we should address that 
> > need <time> to support these formats?
> 
> #1 Adding month or year (imprecise) dates to a calendar Iâ€™m involved 
> in organising events, and as part of this we make plans for events with 
> approximate times. Currently we use a shared calendar plus have a list 
> of events and approximate dates on a private website. Rather than add a 
> list of events to a web page plus add event data to both a calendar, 
> Iâ€™d like to list the events on a web page using <time> and hCalendar 
> or a microdata vocabulary, then add these events to a calendar via a 
> conversion tool. A workaround would be to use full dates, but that gives 
> a false indication of accuracy.

In practice, most calendars have two modes: whole-day, or 
second-to-second. They don't have whole-month. To express a whole-month 
event using iCalendar/vEvent, you just span the month using a start date 
at the start of the month and an end date at the start of the next month. 
No need for any <time> month magic here.

> #2 Restyling dates
> As others have already mentioned, in Japan itâ€™s common to display
> dates as 20-8-2010, 2010-8-20 and 2010å¹´8æœˆ20æ—¥. In addition thereâ€™s this
> fun alternative year system thatâ€™s still widely used, including in
> official documents such as driverâ€™s licenses, based on eras. Currently
> itâ€™s the 22nd year of the Heisei era; å¹³22å¹´8æœˆ20æ—¥. As in Hixieâ€™s example
> of allowing dates to be restyled to follow user conventions, it would
> also be very useful to allow this for year and year-month dates, as
> even Japanese people have difficulty converting between the two
> systems, especially for anything before they were born. Allowing year
> and year-month @datetime values would allow a browser to offer
> localisation of date display including conversion between these two
> date formats. For example:
> Â  Â <time datetime="1935">æ˜9å¹´</time>
> could be automatically restyled to
> Â  Â <time datetime="1935">1935</time>
> (thatâ€™s the ninth year of the ShÅwa era btw ;)

This is an interesting point. I've made a note of this in the spec, so 
that once CSS actually supports rerendering dates (i.e. once we've proven 
that this all works in the first place for the dates and times common to 
most cultures) we can add this too.

   http://html5.org/tools/web-apps-tracker?from=5405&to=5406

> Japanese credit cards frequently list only two digits for expiry year
> (eg â€œ10/15â€), and some Japanese e-commerce sites use a 2-digit input
> for year. Confusingly (well initially for me) these are always the
> abbreviated 4-digit year not the era year. Having this information
> semantically notated would make it more accessible.

How? Surely you just have to type the information like it's on the card.

> #3 Encoding <input> unambiguously
> If this is a use case, it would be nice to be able to encode all the
> datetime-related states of the <input> element.

Why? I understand the use of encoding date and time, and in Japanese I see 
the use for month and year, but why would you ever want to encode the week 
in a style-controllable fashion, say?

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

> Finally, Iâ€™m not sure how much of a use-case this makes but Iâ€™d like 
> to use <time> with microformats and microdata. Not allowing more time 
> formats (year, year-month, month-dayâ€¦) restricts the use of <time> to 
> vocabularies with year-month-day specific dates.

For years and months you don't need to hide the data. It's fine to just 
expose it, as it's human friendly (unlike ISO datetimes).

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