[whatwg] namespaces in html5

[David Karger]

The html5 spec states that
>
> Custom data attributes 
> <http://dev.w3.org/html5/spec/elements.html#custom-data-attribute> are 
> intended to store custom data private to the page or application, for 
> which there are no more appropriate attributes or elements.
>
> These attributes are not intended for use by software that is 
> independent of the site that uses the attributes.
>
and further
>
> It would be inappropriate, however, for the user to use _generic 
> software not associated with_ that music site to search for tracks of 
> a certain length by looking at this data.
>
> This is because these attributes are intended for use by the site's 
> own scripts, and are not a generic extension mechanism for 
> publicly-usable metadata.
>

As I interpret these words, data- attributes are intended to be 
delivered by a server for use by the javascript code that server 
delivers with the page.

The exhibit attributes are not associated with any server, and are not 
associated with any particular data items being delivered by any 
server.  Rather, they are part of  "generic software not associated 
with" the server (see quote above)  and handle _presentation_ of the 
content on the page.

So, while it might be technically valid to use data- prefixes, it 
doesn't seem to fit the intention.


On 7/18/2011 8:53 PM, Tab Atkins Jr. wrote:
> On Mon, Jul 18, 2011 at 7:33 AM, David Karger<karger at mit.edu>  wrote:
>> Yes, we could,  but it doesn't address the two objections I raised to data-
>> prefix:
>> 1.  it isn't actually a data attribute, so prefixing with data seems odd
>> (appearance; minor)
> You seem to have mentally associated the data-* attributes with
> Microdata.  There is no connection between them.  In fact, it's
> impossible for Microdata to use the data-* attributes at all.
>
> data-* attributes are for private script data that is, for whatever
> reason, more convenient to attach directly to a DOM node than to hold
> in a JS structure.  Wanting the data's link to DOM nodes to survive
> serialization is a good reason.
>
>
>> 2.  there's no way to guarantee someone else won't use the same data-exhibit
>> prefix, causing incompatibilities (functionality; major)
> In practice, the risk of prefix collisions has turned out to be
> minimal in many real-world collections, such as jQuery plugins.  We
> expect the same to apply here.  For maximum robustness, simply write
> your library with the ability to accept a different prefix, so that if
> a collision does occur the author can work around it.
>
> ~TJ