W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 12 Oct 2011 11:58:50 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RDxSU-0001Cf-Cz@jessica.w3.org>

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no

--- Comment #39 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-10-12 11:58:44 UTC ---
(In reply to comment #25)
> 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">
> ...all of which pretty much do exactly the same thing: nothing.

My immediate thought was that <data> would have to take different attributes -
which could even be empty/boolean-ish, and which would be used depending on the
kind of data:

<data datetime="2010-10-10">10th of October</data>
<data datetime="">10th of October</data>
<data scalar=10 unit=kg>

Or, eventually - in case of a generic @value attribute - some kind of kind/type
attribute to indicate the kind of data:

<data kind=time value="2010-10-10">10th of October</data>

The only trouble I see is that we are then approaching <object> - in a
literal/syntactic way:

<object type=time data="2010-10-10">10th of October</object>

And since object@data takes URLs, perhasp time as a URI is also a thought:

Was differentiated attributes part of your thinking behind <data>, Mr Editor?

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 Wednesday, 12 October 2011 11:58:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:05 UTC