Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket.

Additionally, be sure to test against the jQuery Edge version to ensure the issue still exists. To get you started, use this boilerplate: http://jsfiddle.net/FrKyN/ Open the link and click to "Fork" (in the top menu) to get started.

If you want a string with no conversion, use .attr() instead.

http://www.learningjquery.com/2011/09/using-jquerys-data-apis

Duplicate of #10174.

Also, you may not be aware, but you're using "e notation"

What if we stop parsing exponent strings as numbers? I doubt anyone intentionally uses them for this purpose, and the change is byte-neutral after https://github.com/jquery/jquery/pull/668 (or +25 bytes before).

(I also looked into fixing #10174. That one's more expensive: an ''additional'' 30+ bytes gzipped if we do it like "" + parseFloat( data ) == data.replace( rnormalizeNum, ... ).)

No way, e-notation is a number, is a number, is a number. typeof 1e6 === "number" I'm not going to special case something just because an edge case doesn't understand JavaScript. I'm half tempted to flat out delete this ticket.

typeof 0x42 === "number" too, but look at this: http://jsfiddle.net/EwTqJ/

Well that's just wrong, but not a test case for this particular ticket.

I bring it up in this ticket because whether data-wtf="0x42" should become 66 or "0x42" hinges in part upon it.

IMO we should be consistently annoying and return 66 since it's a valid JS number.

Yeah, consistency is a bitch, thanks for poiting this out gibson042... now what to do? I suppose all those are valid *json* numbers not just javascript?

JSON syntax excludes hexadecimal notation, but includes exponential.

Also of note is its requirement (not shared by dataAttr) of at least one digit preceding the decimal point (e.g., ".4" is not a JSON number).

So we're good if we do just what we do now (supporting exponent, not hexa)? Since we're supposed to parse JSON data, not Javascript formatted values.

Every attempt is made to convert the string to a JavaScript value (this includes booleans, numbers, objects, arrays, and null) otherwise it is left as a string. -- http://api.jquery.com/data/

It doesn't say anything there about the value following JSON rules; parseInt("0x42"), +"0x42, and Number("0x42") all return the number 66. I wouldn't call the current result "every attempt" or even a "half-ass attempt" for that matter. :)

JSON rules don't affect the outcome since JSON.stringify({value: 0x42}) is {value: 66} with a native number and it never has to convert a string value (just parse the JSON).

We're definitely wrong in parsing hexadecimal strings as 0. If we want to strictly adhere to JSON, we're also wrong in parsing strings like "06" (extraneous leading 0) and ".3" (no digit before decimal point) as numbers.

@gibson042 can you create a new ticket for this bug? Or I suppose we could hijack this one...

Replying to [comment:16 dmethvin]:

@gibson042 can you create a new ticket for this bug? Or I suppose we could hijack this one...

#11309.

Replying to [comment:14 dmethvin]:

> Every attempt is made to convert the string to a JavaScript value (this includes booleans, numbers, objects, arrays, and null) otherwise it is left as a string. -- http://api.jquery.com/data/ It doesn't say anything there about the value following JSON rules; parseInt("0x42"), +"0x42, and Number("0x42") all return the number 66. I wouldn't call the current result "every attempt" or even a "half-ass attempt" for that matter. :)

>

Yeah, but regarding objects and arrays, it states "it must follow valid JSON syntax including quoted property names". Consistency much? ;)

JSON rules don't affect the outcome since JSON.stringify({value: 0x42}) is {value: 66} with a native number and it never has to convert a string value (just parse the JSON).