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

Re: data-* attributes [was: Re: ISSUE-41/ACTION-97 decentralized-extensibility]

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Mon, 19 Oct 2009 20:02:17 +0200
Message-ID: <4ADCA9A9.7000705@xn--mlform-iua.no>
To: James Graham <jgraham@opera.com>
CC: Shelley Powers <shelley.just@gmail.com>, Anne van Kesteren <annevk@opera.com>, Adrian Bateman <adrianba@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, "Tab Atkins Jr." <jackalmage@gmail.com>, Tony Ross <tross@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
James Graham On 09-10-19 17.23:

> Leif Halvard Silli wrote:
>> Shelley Powers On 09-10-19 14.19:
>>> On Mon, Oct 19, 2009 at 7:13 AM, Anne van Kesteren:
>>>> On Mon, 19 Oct 2009 14:03:33 +0200, Shelley Powers:
>>>>> Anne, but then don't we have the use of URIs with namespaces? The only
>>>>> difference is we specify the URI in one place and make a small, easy
>>>>> to use alias for use elsewhere. If anything forcing people to repeat
>>>>> an entire URI with each class name...that could add up, quickly and
>>>>> significantly.
>>>> I wasn't aware that the concept of distributed extensibility or
>>>> decentralized extensibility came with a particular syntax. I'm not 
>>>> convinced
>>>> that authors will have trouble with long identifiers. I actually think
>>>> identifiers with a level of indirection will be more difficult to 
>>>> handle.
>>>>
>>>>> And that doesn't account for the need to extend HTML with elements.
>>>>> Class names could possibly work as attributes, but not as elements.
>>>>> With namespaces we can create both elements and attributes. A superior
>>>>> option.
>>>> For the widgets scenario one could just use data-* attributes. Also, 
>>>> a lot
>>>> of added complexity is not necessarily superior in my book.
>>> But data-* are neither decentralized, nor particularly extensible. In
>>> fact, we've determined in previous discussions that they're not meant
>>> to be used for anything other than by an author for a single author's
>>> needs.
>> In that regard, I wonder why SVGweb operates with a data-path="" 
>> attribute in the Internet Explorer part of that solution ...
> 
> Unless I have misunderstood something, that is a perfectly acceptable 
> use of data-*; a third party js-library is not considered independent of 
> the site (since the site must decide to import the js-library into its 
> pages).

It seems I misinterpreted the purpose of data-path. Sorry. But it 
would have been more clear what its purpose was if it had been 
called data-svgwebuploadpath="" or something like that.

More irritatingly, the SVGweb solution is invalid in so many other 
ways: For the <object> variant, the IE version uses the invalid 
src="" attribute instead of data="". And no attempt is made on 
using OBJECT fallback - instead one uses conditional comments.

> To take a slightly different example, it is OK to have data-marquee that 
> is used by a script that the author includes in the page to implement 
> marquee effects. But it is not permitted for a user agent to provide its 
> own marquee effects based on the presence of a [data-]marquee attribute.

Right, it seems obvious that user agents should not bind behavior 
to data-*.

But then, in the W3C blog 16th of February this year, Dan 
criticized Palm for introducing their own custom attribute with 
the prefix x-mojo-*="", with these words: [1]

]]The suggestion in the HTML 5 draft is data-* attributes. The 
ARIA draft suggests @role. The Palm design looks like new 
information for issue-41, Decentralized-extensibility, in the HTML 
WG.[[

[1] http://www.w3.org/QA/2009/02/palm_webos_approach_to_html_ex


> Is the distinction clear now? It is likely that the spec needs 
> clarification on this point.

Having said the above, the draft says:

   ]]These attributes are not intended for use by software that is 
independent of the site that uses the attributes.[[

Except user agents, when is a software independent of the site 
that uses the attributes?
-- 
leif halvard silli
Received on Monday, 19 October 2009 18:02:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC