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.

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.

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

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.

Replying to [comment:5 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.

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/

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.

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/

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.

#8326 is a duplicate of this ticket.

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.

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

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

Changeset: 8c318bf41412d493604beed1879c4a273ff05a57

#9413 is a duplicate of this ticket.

#9461 is a duplicate of this ticket.