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

Hi Steve,

We have been discussing it, though communication has been somewhat delayed by TPAC and associated travel. We will post our response soon.

 - Maciej

On Nov 2, 2011, at 3:45 PM, Steve Faulkner wrote:

> Dear Chairs, 
> 
> I believe it is difficult for working group members to comprehend the chairs apparent vaccilation, in light of the negative effects this change has had upon trust in the W3C HTML5 specification within the wider development community.
> 
> The bug[1] that lead to this change was filed (Reported: 2011-07-14 05:48 UTC by Ian 'Hixie' Hickson ) after last call cut off, it's resolution is highly controversial, it by no measure has the consensus of the working group and furthermore it was not even filed against the "LC1 HTML5 spec", but against "other Hixie drafts".
> 
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240
> 
> 
> with regards
> Stevef
> 
> On 31 October 2011 11:19, Paul Cotton <Paul.Cotton@microsoft.com> wrote:
> The current description of the Enhanced Change Control which covers “reverts” is in the current WG Decision Policy (V2):
> 
> http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#enhanced-cc
> 
>  
> 
> /paulc
> 
> HTML WG co-chair
> 
>  
> 
> Paul Cotton, Microsoft Canada
> 
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> 
> Tel: (425) 705-9596 Fax: (425) 936-7329
> 
>  
> 
> From: Steve Faulkner [mailto:faulkner.steve@gmail.com] 
> Sent: Sunday, October 30, 2011 6:50 PM
> To: Philip Jägenstedt
> Cc: public-html@w3.org
> Subject: 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)
> 
> 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> has been followed strictly in this instance -- <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
> 
> The default WordPress theme, 2011, uses <time> and pubdate on blog
> <article>s 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>.
> 
>  
> 
> [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>.
> 
>  
> 
> [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)
> 
> 
> 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).
> 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 
> 
> 
> 
> 
> -- 
> 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 
>