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. `._.-(,_..'--(,_..'`-.;.'