Re: Times, dates, and related topics

On Sat, 2 May 2009, Jens Meiert wrote:
> >
> > Over the past month or so I have collected about 142 e-mails on the 
> > topic of the <time> element and other time-related subjects. This is 
> > an attempt to address that feedback.
> 
> Regarding the resulting “time” element section in the spec [1] I 
> cannot but express my concerns that in reality, authors won’t use the 
> element this way. Despite all understandable, valid reasoning behind it, 
> the “time” element currently doesn’t seem to match an author’s 
> and user’s model on how to mark up “time.”
>
> Thus, I think we can expect authors to use “time” for stuff like 
> <time>500 BC</time>, <time>2 pm</time>, <time>2025</time>, and maybe 
> even <time>yesterday</time>.
> 
> Even though there aren’t any numbers backing this claim 
> up—understandably so—I wonder if we can make the spec a bit more 
> tolerant?

Well, while all the above exampels would cause a validator to say there 
was an error, the result won't be a problem -- the browsers will basically 
just ignore the <time> elements in these cases, so I don't think it's a 
real problem.

I mean, we already see huge misuse of HTML elements. I see no reason to 
believe this would be any worse, and at least the spec is clear on what 
the right usage is.


On Sun, 3 May 2009, Smylers wrote:
> 
> Such authors would presumably be those who haven't read the spec or 
> don't care about it.  Since validators can easily catch the above, 
> they'd also be people who don't care about validation.
> 
> Following the current spec, the preferred markup for each of the above 
> is simply not to use any tags at all -- which is effectively how user 
> agents will treat them anyway, since no valid date or time can be parsed 
> from them.  So users get the same experience either way.
> 
> Obviously it would be better if all authors completely complied with the 
> spec.  But as non-compliance goes the above seem relatively harmless.

Right.


On Tue, 5 May 2009, Jens Meiert wrote:
> 
> Well, I think it’s at least interesting that we’re so keen to 
> include elements like e.g. “header” and “footer” to reflect 
> common practice, but might fail anticipating future common practice when 
> it comes to other elements.

Well we can always make <time> legal for arbitrary content later if we 
find there's a good reason to do so. I don't think we need to 
pre-emptively make the element allow anything.


> > Following the current spec, the preferred markup for each of the above 
> > is simply not to use any tags at all -- which is effectively how user 
> > agents will treat them anyway, since no valid date or time can be 
> > parsed from them.  So users get the same experience either way.
> 
> Actually, I’d rather take that as a point to remove the “time” 
> element from the spec (which is not what I wanted to suggest). 
> “Semantic fuzziness” of certain elements has already been a problem 
> with former HTML specifications.

Is <time> semantically fuzzy? It seems pretty clear to me.


On Tue, 5 May 2009, Smylers wrote:
> 
> Well at least once difference between "common practice" and "future 
> common practice" is that the former is supported by data showing how 
> widespread it actually is.  Once <time> is in the wild, HTML 6 could use 
> that experience to extend it.

Right.


> It _would_ be a problem if an author mis-understanding <time> gave it a 
> value which was syntactically valid but was intended to convey different 
> meaning from that ascribed by HTML 5.  But that seems very unlikely.

Indeed.

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