Should data-foo-bar be accessible via .data( 'fooBar' ) as well as .data( 'foo-bar' ) ?

[cowboy]

I was looking at  the section of the HTML5 draft on custom data attributes and noticed this text:

Hyphenated names become camel-cased. For example, data-foo-bar="" becomes element.dataset.fooBar.

Is this something jQuery should handle?

This is how jQuery currently behaves:

$('<div data-foo-bar="123"/>').data( 'foo-bar' ); // 123
$('<div data-foo-bar="123"/>').data( 'fooBar' ); // undefined

Should jQuery behave thusly?

$('<div data-foo-bar="123"/>').data( 'foo-bar' ); // 123
$('<div data-foo-bar="123"/>').data( 'fooBar' ); // 123

[john]

I disagree - and intentionally did not implement this functionality. Implementing it would require two getAttribute lookups for every camel-cased attribute name. If the user asks for .data("fooBar") are they looking for data-fooBar or data-foo-bar? Not to mention the fact that the API is simpler and more intuitive as a result - the users just use the names that they see in front of them, no need to deal with messy camel-casing.

[anonymous]

If future standard requires to convert hyphenated names to camel-case, shouldn't jQuery honor that standard or is it IE all over again? It's more confusing when someone (me) reads html5 draft and tries to use camel-cased names in jQuery instead of hyphenated names used in html and can't figure out why it does not work.

[snover]

John, your assertion doesn’t make any sense to me. HTML5 attributes are case-insensitive, and are automatically coerced to lowercase. The spec requires this. data-foobar is the same as data-FOOBAR or data-fooBar or data-FoObAr. The current behaviour is backwards from what it should be, according to the spec, and does not match what occurs elsewhere with identical string transformations (in $.fn.css, where both font-size and fontSize work).

 spec reference

[dmethvin]

Uh...what exactly is broken here? Seems like we're consistent with getAttribute:

 http://jsfiddle.net/dmethvin/cvRsE/

I think we all agree that once it's in .data() the name needs to match exactly if you want the previous data. So the attribute might be named data-foo-bar but if you use .data("foo-BAR") to access the data the first time you must use foo-BAR now and forever, amen. If you use .data("FOO-bar") later we'll go out and get the data attribute again and put it in a _different_ name.

[anonymous]

Replying to dmethvin: Like ticket submitter wrote, problem is that in HTML5 specs hyphenated names become camel-cased. For example, data-foo-bar="" becomes element.dataset.fooBar. So it would make sense if jQuery data() uses same names as native dataset.

[rwaldron]

I think we should strive to handle data attributes as close to the native implementation as possible.

I've altered dmethvin's fiddle to illustrate the difference in handling.

 http://jsfiddle.net/rwaldron/bfyM5/1/

[paul.irish]

While it'd be nice to allow the camelCase based getting, it doesn't seem necessary.

This isn't the dataset() method, so API consistency doesn't seem critical.

[rfoster]

The problem that I face is when I have several custom attributes. I want to make a single call to .data() to get all of the attributes at once and save them into a variable. However, any multi-word attributes are not accessible in that variable. So I am forced to make multiple calls to .data() to get each attribute separately. Using camelCase would fix this bug.

 http://jsfiddle.net/mAJbL/1/

[andyfowler]

I'm +1 on camelcasing -- I think that el.data() *should* behave like the spec'd .dataset attribute, since it pulls in all data- attrs.

[snover]

#8326 is a duplicate of this ticket.

[jeoffw]

Here's one example where camel-case would really help. Suppose I want to specify plugin options declaratively within data-* attributes. Plugin attributes are often case-sensitive, but our current mapping from HTML5 data attributes provides no way to specify case-sensitive options.

Here's an example using jquery-ui accordion:  http://jsfiddle.net/g8CkE/7/

In the example, the accordions div has data-auto-height="false" and data-autoHeight="false" but neither of them map to "autoHeight" which is what the plugin expects.

[alexis.abril]

I've written a patch for this, not yet submitted a pull request, but have a demo up and running at the following:

 http://jsfiddle.net/evysr/

The patch is at:

 https://github.com/alexisabril/jquery/commit/dd98f982b4e411c6abc127e3190044d8cd6a9d89

My original intent was to use the native dataset as a conditional, allowing for progressive enhancement as browsers(other than Chrome) start to implement this method. However, due to the spec being so new, there is currently no way to traverse a DOMStringMap; specifically call the length of the object.

For the time being, I'm doing simple string modification to allow jQuery to match attributes to the Html5 spec.

 http://dev.w3.org/html5/spec/Overview.html#domstringmap

[Alexis Abril]

Fixes #7328. When getting data- attributes, after-cap any embedded dashes per the W3C HTML5 spec.

Changeset: 8c318bf41412d493604beed1879c4a273ff05a57

[rwaldron]

#9413 is a duplicate of this ticket.

[rwaldron]

#9461 is a duplicate of this ticket.