Skip to main content

Bug Tracker

Side navigation

#14376 closed bug (migrated)

Opened September 20, 2013 04:54AM UTC

Closed October 21, 2014 12:20AM UTC

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

Reported by: Owned by: rwaldron
Priority: low Milestone: 1.12/2.2
Component: data Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:

version affected: any (1.10.1)

browser: any (chrome)

OS: any (windows 7 64bit)

For the following html

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


var div = $('div');


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

Actual result: an empty object


Attachments (0)
Change History (15)

Changed September 27, 2013 10:50AM UTC by ameyms comment:1

Seems to be happening because we camelize the key before passing it to

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)

Changed September 27, 2013 12:27PM UTC by dmethvin comment:2

component: unfileddata
milestone: None1.11/2.1
priority: undecidedlow
status: newopen


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.

Changed November 05, 2013 03:20PM UTC by rwaldron comment:3

owner: → rwaldron
status: openassigned

Changed November 05, 2013 04:20PM UTC by rwaldron comment:4

Changed November 06, 2013 03:49PM UTC by rwaldron comment:5

resolution: → cantfix
status: assignedclosed

...was closed as a duplicate of this:

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.

Changed November 06, 2013 04:02PM UTC by rwaldron comment:6

Changed November 06, 2013 05:54PM UTC by gnarf comment:7

resolution: cantfix
status: closedreopened

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.

Changed November 11, 2013 05:57PM UTC by dmethvin comment:8

status: reopenedopen

Changed November 13, 2013 03:07PM UTC by rwaldron comment:9

Changed December 16, 2013 04:58PM UTC by dmethvin comment:10

milestone: 1.11/

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.

Changed December 17, 2013 05:55PM UTC by malsup comment:11

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

Changed January 03, 2014 04:23AM UTC by dmethvin comment:12

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

Changed January 17, 2014 12:14AM UTC by malsup comment:13

Replying to [comment:12 dmethvin]:

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


See thread:

Changed March 04, 2014 02:46PM UTC by dmethvin comment:14


Changed October 21, 2014 12:20AM UTC by m_gol comment:15

resolution: → migrated
status: openclosed