Comment author: 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)

Comment author: 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.

Comment author: rwaldron

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

Comment author: rwaldron

 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.

Comment author: rwaldron

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

Comment author: 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.

Comment author: rwaldron

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

Comment author: 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.

Comment author: malsup

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

Comment author: dmethvin

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

Comment author: 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

Related to http://bugs.jquery.com/ticket/14799 :

assert.equal( jQuery("<div>").data({ "a-b": 1 }).data( "a-b", 2 ).data( "a-b" ), 2 )

And per #1515 (comment) , we want the "Embrace HTML5" option:

• camelCase data-* attributes into the data object on first access
• set only camelCase key on .data( key, val ) (setter)
• camelCase all the added keys on .data( obj ) (bulk setter)
• look for only camelCase key on .data( key ) (getter)
• ignore direct manipulation from operations on .data()

/cc @rwaldron

@markelog what's up? I was following this, but there hasn't been any activity lately.

I'll grab this for 3.0, if that's alright with Rick.

@timmywil sure, it shouldn't be too much work TBH. Mostly deleting code paths and associated tests. The tricky part is making sure that manipulation tests pass as well, since data tests exist there also