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

Hallo.

I’m in full agreement with the revert request. data is as general as
div or span, I don’t see any advantage by using it. By that logic you
could just mark up anything with divs and microdata/rdfa/microformats
and be done. That would be a mess. Time is an elegant way that
provides something that people are already using, like header and
footer. It has adoption with WordPress and will be incorporated into
Drupal.

With regards,
Eric Eggert

On Sun, Oct 30, 2011 at 20:59, 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.
>
>
>
> [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/
> [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.
> [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.
> [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.
>
> [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".
> 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.
> [7] The spec has an example of a sortable table. What does <data value="">
> bring that <span data-value=""> doesn't?
>
>
> --
> 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
>
>





--

outline - we web.

Sandra Kallmeyer und Eric Eggert GbR
Hauptstraße 101–105
45219 Essen-Kettwig
GERMANY

USt-IdNr.: DE275406670

phone    +49 (0)2054 1255740
mobile    +49 (0)151 41932204

info@outlinewebdesign.com
www.outlinewebdesign.com

Spielregeln
http://www.outlinewebdesign.com/spielregeln.php

Received on Monday, 31 October 2011 10:53:59 UTC