`.data()` doesn't handle the attributes with digits in the name well

[zerkms@…]

version affected: any (1.10.1) browser: any (chrome) OS: any (windows 7 64bit)

For the following html

<div data-foo-42="bar"></div>

and

var div = $('div');

console.log(div.data());

javascript code I expect to see the object with one property.

Actual result: an empty object

jsfiddle: ​http://jsfiddle.net/nWCKt/

[ameyms]

Seems to be happening because we camelize the key before passing it to dataAttr() function. dataAttr() then tries to reconstruct the hyphenated attribute name and does so incorrectly.

Consider following example:

data-foo-bar --> fooBar --> data-foo-bar (correct)

data-foo-42 --> foo42 --> data-foo42 (incorrect)

[dmethvin]

Ref: ​http://www.w3.org/TR/2011/WD-html5-20110525/elements.html#embedding-custom-non-visible-data-with-the-data-attributes

It seems like we shouldn't take out the hyphen unless the following char is /[a-z]/. However that's inside jQuery.camelCase() so making that change could affect many other situations outside data attributes.

[Rick Waldron]

This lead to filing: ​https://code.google.com/p/chromium/issues/detail?id=315125&thanks=315125&ts=1383668374

[Rick Waldron]

​https://code.google.com/p/chromium/issues/detail?id=315125&thanks=315125&ts=1383668374

...was closed as a duplicate of this: ​https://code.google.com/p/chromium/issues/detail?id=171175

Based on the spec:

For each name in list, for each U+002D HYPHEN-MINUS character (-) in the name that is followed by a lowercase ASCII letter, remove the U+002D HYPHEN-MINUS character (-) and replace the character that followed it by the same character converted to ASCII uppercase.

the solution would be to _not_ remove hyphens when they are immediately followed by numbers, so that data-foo-42 would produce a key called foo-42. Unfortunately, this is a compatibility breaking change—one that we actually have unit tests to support.

[Rick Waldron]

​https://github.com/jquery/api.jquery.com/issues/383

[gnarf]

This is one of those weird situations where we "cantfix" but we probably should... Re-opening to discuss the ultimate fate of this one at the next meeting.

[Rick Waldron]

This has been fixed in Chrome ​https://code.google.com/p/chromium/issues/detail?id=171175

[dmethvin]

This is a behavior change so it won't go into 1.11/2.1, but I think we'll need to deal with it.

[malsup]

This is a breaking change when migrating from 1.9 to 2.x.

[dmethvin]

@malsup, the two branches seem to work the same with the OP's test case. Is there some other test case?

[malsup]

Replying to dmethvin:

@malsup, the two branches seem to work the same with the OP's test case. Is there some other test case?

@dmethvin See thread: ​https://github.com/jquery/api.jquery.com/issues/383

[m_gol]

Migrated to ​https://github.com/jquery/jquery/issues/1751