Bug Tracker

Opened 13 years ago

Closed 12 years ago

Last modified 12 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 13 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 13 years ago by john

Component: unfileddata

comment:3 Changed 13 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 13 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 13 years ago by snover (previous) (diff)

comment:5 Changed 13 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 13 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 13 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 13 years ago by snover

Milestone: 1.5
Priority: undecidedhigh
Status: reopenedopen

comment:9 Changed 13 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 13 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 13 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 13 years ago by snover

#8326 is a duplicate of this ticket.

comment:13 Changed 13 years ago by snover

Milestone: 1.6
Priority: highblocker

comment:14 Changed 13 years ago by jitter


comment:15 Changed 13 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 12 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 12 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 12 years ago by Rick Waldron

#9413 is a duplicate of this ticket.

comment:19 Changed 12 years ago by Rick Waldron

#9461 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.