Bug Tracker

Ticket #7328 (closed enhancement: fixed)

Opened 4 years ago

Last modified 2 years ago

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:
Blocking: Blocked by:

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

Change History

comment:1 Changed 4 years ago by john

  • Status changed from new to closed
  • Resolution set to wontfix
  • Milestone 1.5 deleted

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 4 years ago by john

  • Component changed from unfiled to data

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

  • Status changed from closed to reopened
  • Resolution wontfix deleted

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 4 years ago by snover (previous) (diff)

comment:5 follow-up: ↓ 6 Changed 4 years ago by 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.

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

comment:8 Changed 4 years ago by snover

  • Priority changed from undecided to high
  • Status changed from reopened to open
  • Version changed from 1.4.3 to 1.4.4
  • Milestone set to 1.5

comment:9 Changed 4 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 4 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.

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

comment:11 Changed 4 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 4 years ago by snover

#8326 is a duplicate of this ticket.

comment:13 Changed 4 years ago by snover

  • Priority changed from high to blocker
  • Milestone set to 1.6

comment:14 Changed 4 years ago by jitter

  • Version changed from 1.4.4 to 1.5

comment:15 Changed 3 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 3 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:

 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

comment:17 Changed 3 years ago by Alexis Abril

  • Status changed from open to closed
  • Resolution set to fixed

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

Changeset: 8c318bf41412d493604beed1879c4a273ff05a57

comment:18 Changed 3 years ago by rwaldron

#9413 is a duplicate of this ticket.

comment:19 Changed 3 years ago by rwaldron

#9461 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.