Re: revert request for http://html5.org/r/6783 dropping of time element, adding of data element

Hi Philip,

I refer you to this email: Enhanced change control after the Last Call
cutoff
http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html
I have based the revert request on the details outlined there in.

regards
Stevef

On 30 October 2011 14:56, Philip Jägenstedt <philipj@opera.com> wrote:

> On Sun, 30 Oct 2011 20:59:02 +0100, Steve Faulkner <
> faulkner.steve@gmail.com> wrote:
>
>  the editor of the HTML5 specification has made a change to the
>> specification that is not supported for good reasons (see below, source:
>> http://willyou.typewith.me/p/**9Zl7I2dOKs<http://willyou.typewith.me/p/9Zl7I2dOKs>
>> )
>>
>> I therefore request a revert of this change http://html5.org/r/6783, so
>> that it can be further discussed and decided within the consensus based
>> HTML WG process.
>>
>
> It seems to me that <http://dev.w3.org/html5/**decision-policy/decision-**
> policy.html <http://dev.w3.org/html5/decision-policy/decision-policy.html>>
> has been followed strictly in this instance -- <http://www.w3.org/Bugs/**
> Public/show_bug.cgi?id=13240<http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240>>
> was open for 3 months before the spec change, with lots of people
> commenting. We are now at step 2 of the process: editor's response.
> Reverting is not a documented part of that process, but under which
> criteria the chairs demand it anyway is unclear to me. (That it will become
> an ISSUE seems a given.)
>
>
>  [1] The time element, while being limited to a very specific use case, is
>> simple. Uptake so far has been good, as far as I can tell. There are many
>> blogs outside who already use this, and the Boston Globe has them, too:
>> http://bostonglobe.com/ Also, there is adoption by the microformats
>> community: http://microformats.org/wiki/**html5#time_element<http://microformats.org/wiki/html5#time_element>
>>
>> The default WordPress theme, 2011, uses <time> and pubdate on blog
>> <article>s http://twentyelevendemo.**wordpress.com/<http://twentyelevendemo.wordpress.com/>
>>
>
> What harm comes from <time> no longer being valid? AFAIK, Opera is the
> only browser that ever implemented any kind of support for <time> (DOM
> interface and in microdata), but even then it's rendered just like any
> other element.
>
>
>  [2] The data element is just a container like div or span. The only
>> difference is the value attribute which could be made valid for (nearly)
>> every element, thus eliminating the need for data completely.
>>
>
> A global attribute intuitively seems like a good idea, but it becomes
> quite confusing in cases like this:
>
> <img src=foo itemprop=img value=bar>
>
> Is itemValue foo (resolved as a URL) or bar? If it is bar, is it also
> resolved as a URL? It seems like setting itemValue would modify different
> underlying attributes depending on what attributes are already present,
> which is unprecedented AFAIK.
>
> This was discussed in the bug, see e.g. <http://www.w3.org/Bugs/**
> Public/show_bug.cgi?id=13240#**c17<http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240#c17>
> >.
>
>
>  [3] It makes no sense to remove the pubdate attribute which was a fast and
>> convenient way to specify the publish date of an article. Now this
>> specification is much more complicated, you’d need either a complete hAtom
>> microformat or some kind of rather complex microdata. I think those two
>> won’t get any faster adoption than time, risking that the date of an
>> information might get lost in non-semantic code.
>>
>
> That seems a rather tolerable risk, given that the information is
> syndicated in RSS/Atom anyway. Throwing away pubdate also means that
> creation data and modification date can be handled in a uniform way.
>
>
>  [4] <time> (or its precursor, <date>) has an obvious semantic (easy to
>> learn, easy to read). Because it's  restricted to dates and times, the
>> datetime attribute has a specific syntax that can be checked by a
>> validator. <data value=""> has no such built-in syntax, as it's for
>> arbitrary data, so can't be machine validated, leading to more erroneous
>> dates being published. Therefore, the reliability and thus the utility of
>> the information being communicated in machine-readable format diminishes.
>>
>
> The fixed syntax had its issues as well, in particular
> <time>2011-10</time> was always invalid, so it was never possible to use
> for fuzzier dates, something that dissuaded me from using it. It also can't
> be used for all the kinds of times that schema.org has, as it was
> actually a subset of ISO 8601 not including durations or repeating
> intervals.
>
> Also, if one publishes data using <data value=""> and microdata, one will
> want to use vocabulary-specific validation to check all of the data, not
> just the dates. Vocabulary-aware validation is admittedly vapor-ware right
> now, but see <http://bugzilla.validator.nu/**show_bug.cgi?id=851<http://bugzilla.validator.nu/show_bug.cgi?id=851>
> >.
>
>
>  [5] The spec for <data> says "A script loaded by the page (and thus privy
>> to the page's internal convention of marking up dates and times using the
>> data element) could scan through the page and look at all the data
>> elements
>> therein to create an index of dates and times." (
>> http://www.whatwg.org/specs/**web-apps/current-work/**
>> multipage/text-level-**semantics.html#the-data-**element<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-data-element>
>> )
>>
>>
>> This is a retrograde step from the <time> element that uses a wider
>> standard/ convention for dates, such as ISO 8601 because now the script
>> must be "privy to the page's internal convention".
>>
>
> I don't understand, how does this make a difference to scripts? It can
> either sort the values textually or by converting them to Date object, both
> with <time> and <data>. It seems that <data> is just more flexible, as
> formats like "2011-10" or "2011-{10,11}" could now be used.
>
>
>  6] <data> as an element is public data. data-* attributes are private
>> (only
>> for scripts on a page, not external crawlers: "These attributes are not
>> intended for use by software that is independent of the site that uses the
>> attributes."
>> http://www.whatwg.org/specs/**web-apps/current-work/**
>> multipage/elements.html#**embedding-custom-non-visible-**
>> data-with-the-data-*-**attributes<http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes>
>> ).
>> This is highly confusing.
>>
>
> You just pointed out precisely where the difference is, so to whom is it
> confusing?
>
>
>  [7] The spec has an example of a sortable table. What does <data value="">
>> bring that <span data-value=""> doesn't?
>>
>
> <data value=""> can be used with microdata while data-* attributes can't,
> for the reason you stated in the previous point.
>
> --
> Philip Jägenstedt
> Core Developer
> Opera Software
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html