[Bug 13240] Consider replacing <time> with <data>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240

--- Comment #28 from Michael[tm] Smith <mike@w3.org> 2011-08-09 06:45:13 UTC ---
(In reply to comment #25 from Hixie)
> I'm definitely leaning towards doing this. The alternative seems to be to have
> a whole slew of elements for this kind of thing:
> 
>    <time datetime="2010-10-10">
>    <number value=10>
>    <scalar value=10 unit=kg>
>    <duration value="1h10m2.2s">
>    <timerange start="2010-01-01" end="2010-02-02">
>    <enum value="spring">

If that's a complete list, that's not really much of a slew. It's six elements
whose purposes are very clear from their name, versus one new element whose
name does very little to make its purpose clear. And even if the above is not a
complete list, I think the list of new elements to consider is still finite and
would not be much larger than what you have above.

> ...all of which pretty much do exactly the same thing: nothing.

If the expectation is that UAs would not ever be doing anything either with any
of the elements suggested in that list or with the proposed <data> element,
then I guess it matters a lot less which ends up being added.

But as far as elements that UAs are actually expected to do something with, I
think that experience with the <input> element has shown that adding a generic
element with an attribute for subtyping it into multiple subtypes (now more
than a dozen) brings a number of hidden costs and complications. The subtyping
essentially makes it into multiple logical abstract "elements" anyway, and the
subtyping-by-attribute mechanism just makes it look like there's less
complexity around it than there actually is.

I think subtyping in that way is a serious design mistake and an anti-pattern
that should not be perpetuated further -- even for an element that does nothing
in UAs. We'd be better off in the long run adding nothing at all than we would
be adding something like that.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 9 August 2011 06:45:22 UTC