Bug Tracker

Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#7328 closed enhancement (fixed)

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

Reported by: cowboy Owned by:
Priority: blocker Milestone: 1.6
Component: data Version: 1.5
Keywords: Cc:
Blocked by: Blocking:


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

Change History (19)

comment:1 Changed 7 years ago by john

Milestone: 1.5
Resolution: wontfix
Status: newclosed

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.

comment:2 Changed 7 years ago by john

Component: unfileddata

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by snover

Resolution: wontfix
Status: closedreopened

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

Last edited 6 years ago by snover (previous) (diff)

comment:5 Changed 6 years ago by dmethvin

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


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.

comment:6 in reply to:  5 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by Rick Waldron

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.


comment:8 Changed 6 years ago by snover

Milestone: 1.5
Priority: undecidedhigh
Status: reopenedopen

comment:9 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by 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.


comment:11 Changed 6 years ago by 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.

comment:12 Changed 6 years ago by snover

#8326 is a duplicate of this ticket.

comment:13 Changed 6 years ago by snover

Milestone: 1.6
Priority: highblocker

comment:14 Changed 6 years ago by jitter


comment:15 Changed 6 years ago by 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.

comment:16 Changed 6 years ago by 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:


The patch is at:


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.


comment:17 Changed 6 years ago by Alexis Abril

Resolution: fixed
Status: openclosed

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

Changeset: 8c318bf41412d493604beed1879c4a273ff05a57

comment:18 Changed 6 years ago by Rick Waldron

#9413 is a duplicate of this ticket.

comment:19 Changed 6 years ago by Rick Waldron

#9461 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.