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

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
(+spec)
 
(11 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.


== Candidates ==
== Candidates ==
<pre>
<pre>
<span custom:my-thing="50" custom:my-other-thing="4,5,1,2">bla bla</span>
<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';
</pre>
</pre>
== Rejected ==


<pre>
<pre>
<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 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.)
</pre>
</pre>


<pre>
<pre>
<span data-thing="50" data-my-doohickey="4,5,1,2">bla bla</span>
<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
if (span.dataset.thing > 10) { ... }
they do now, violating the spec, instead of using it.)
span.dataset.doohickey = '1,2,3,4';
</pre>
</pre>


== Rejected ==
<pre>
<pre>
<span><param name=my-thing value="50"><param name=my-other-thing value="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-".)
</pre>
</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.
''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