Skip to main content

Bug Tracker

Side navigation

#7328 closed enhancement (fixed)

Opened October 27, 2010 03:19PM UTC

Closed April 10, 2011 07:17PM UTC

Last modified March 10, 2012 03:06AM UTC

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:
Description

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
Attachments (0)
Change History (19)

Changed October 27, 2010 03:49PM UTC by john comment:1

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.

Changed October 27, 2010 03:49PM UTC by john comment:2

component: unfileddata

Changed November 12, 2010 09:01AM UTC by anonymous comment:3

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.

Changed November 22, 2010 04:18AM UTC by snover comment:4

_comment0: John, your assertion doesn’t make any sense. 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`. \ \ [http://www.w3.org/TR/html5/elements.html#embedding-custom-non-visible-data-with-the-data-attributes spec reference]1290804675201618
_comment1: John, your assertion doesn’t make any sense. 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). \ \ [http://www.w3.org/TR/html5/elements.html#embedding-custom-non-visible-data-with-the-data-attributes spec reference]1291331806053633
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

Changed December 02, 2010 03:10AM UTC by dmethvin comment:5

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.

Changed December 02, 2010 08:23AM UTC by anonymous comment:6

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.

Changed December 02, 2010 03:21PM UTC by rwaldron comment:7

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/

Changed December 15, 2010 03:42AM UTC by snover comment:8

milestone: → 1.5
priority: undecidedhigh
status: reopenedopen
version: 1.4.31.4.4

Changed December 20, 2010 01:03AM UTC by paul.irish comment:9

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.

Changed January 11, 2011 11:49AM UTC by rfoster comment:10

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/

Changed January 26, 2011 06:22PM UTC by andyfowler comment:11

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.

Changed February 19, 2011 07:50PM UTC by snover comment:12

#8326 is a duplicate of this ticket.

Changed February 19, 2011 07:50PM UTC by snover comment:13

milestone: → 1.6
priority: highblocker

Changed February 20, 2011 01:38PM UTC by jitter comment:14

version: 1.4.41.5

Changed March 24, 2011 03:57PM UTC by jeoffw comment:15

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.

Changed April 06, 2011 08:25AM UTC by alexis.abril comment:16

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

Changed April 10, 2011 07:17PM UTC by Alexis Abril comment:17

resolution: → fixed
status: openclosed

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

Changeset: 8c318bf41412d493604beed1879c4a273ff05a57

Changed May 24, 2011 04:58PM UTC by rwaldron comment:18

#9413 is a duplicate of this ticket.

Changed May 30, 2011 03:38PM UTC by rwaldron comment:19

#9461 is a duplicate of this ticket.