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<[email protected]> 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
