A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
CustomData: Difference between revisions
(Value of site-specific prefixes) |
(+spec) |
||
(5 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
{{obsolete|spec=[http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes HTML Standard: Embedding custom non-visible data with the data-* attributes]}} | |||
Here are some ideas for how to include custom data in HTML documents. | Here are some ideas for how to include custom data in HTML documents. | ||
Line 27: | Line 29: | ||
<span custom-my-thing="50" custom-my-other-thing="4,5,1,2">bla bla</span> | <span custom-my-thing="50" custom-my-other-thing="4,5,1,2">bla bla</span> | ||
(rejected because "custom-" is not as good a prefix as "data-".) | (rejected because "custom-" is not as good a prefix as "data-".) | ||
</pre> | |||
If "custom" was site-specific, then wouldn't, e.g. "markbaker-my-thing" be better than a global "data-my-thing"? Otherwise there's a pretty good chance of collisions. Much more author friendly than namespaces. "data-" suggests that a central registry/wiki would be required to avoid collision. | If "custom" was site-specific, then wouldn't, e.g. "markbaker-my-thing" be better than a global "data-my-thing"? Otherwise there's a pretty good chance of collisions. Much more author friendly than namespaces. "data-" suggests that a central registry/wiki would be required to avoid collision. | ||
''The whole feature is site-specific -- who are you going to collide with? In syndication environments, of course, you could provide per-site prefixes as a convention, e.g. data-markbaker-thing, but if you're syndicating Web apps you're much more likely to run into problems with JS globals first. --Hixie'' |
Latest revision as of 16:14, 10 November 2012
This document is obsolete.
For the current specification, see: HTML Standard: Embedding custom non-visible data with the data-* attributes
Here are some ideas for how to include custom data in HTML documents.
Candidates
<span data-thing="50" data-doohickey="4,5,1,2">bla bla</span> if (span.dataSet.thing > 10) { ... } span.dataSet.doohickey = '1,2,3,4';
Rejected
<span custom:my-thing="50" custom:my-other-thing="4,5,1,2">bla bla</span> (rejected because colons have special meaning in XML and so this would lead to the HTML and XML DOM representations differing, which violates our intent to keep the DOM accessors serialisation-agnostic.)
<span><param name=my-thing value="50"><param name=my-other-thing value="4,5,1,2">bla bla</span> (rejected because it's so verbose that people would likely just do what they do now, violating the spec, instead of using it.)
<span custom-my-thing="50" custom-my-other-thing="4,5,1,2">bla bla</span> (rejected because "custom-" is not as good a prefix as "data-".)
If "custom" was site-specific, then wouldn't, e.g. "markbaker-my-thing" be better than a global "data-my-thing"? Otherwise there's a pretty good chance of collisions. Much more author friendly than namespaces. "data-" suggests that a central registry/wiki would be required to avoid collision.
The whole feature is site-specific -- who are you going to collide with? In syndication environments, of course, you could provide per-site prefixes as a convention, e.g. data-markbaker-thing, but if you're syndicating Web apps you're much more likely to run into problems with JS globals first. --Hixie