#11297 closed bug (duplicate)
jQuery.data returning wrong data
Reported by: | anonymous | Owned by: | anonymous |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | 1.7.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Latest Chrome (Stable) and Safari (Mac OS 10.7)
HTML:
<p data-foo="7213e2">7213e2</p>
JavaScript:
console.log($('p').data('foo')) => 721300
Expected:
$('p').data('foo') => 7213e2
Change History (18)
comment:1 Changed 11 years ago by
Owner: | set to anonymous |
---|---|
Status: | new → pending |
comment:2 Changed 11 years ago by
Resolution: | → duplicate |
---|---|
Status: | pending → closed |
If you want a string with no conversion, use .attr()
instead.
http://www.learningjquery.com/2011/09/using-jquerys-data-apis
comment:5 Changed 11 years ago by
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, ... )
.)
comment:6 Changed 11 years ago by
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.
comment:7 Changed 11 years ago by
typeof 0x42 === "number"
too, but look at this: http://jsfiddle.net/EwTqJ/
comment:8 Changed 11 years ago by
Well that's just wrong, but not a test case for this particular ticket.
comment:9 Changed 11 years ago by
I bring it up in this ticket because whether data-wtf="0x42" should become 66
or "0x42"
hinges in part upon it.
comment:10 Changed 11 years ago by
IMO we should be consistently annoying and return 66 since it's a valid JS number.
comment:11 Changed 11 years ago by
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?
comment:12 Changed 11 years ago by
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).
comment:13 Changed 11 years ago by
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.
comment:14 follow-up: 18 Changed 11 years ago by
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).
comment:15 Changed 11 years ago by
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.
comment:16 follow-up: 17 Changed 11 years ago by
@gibson042 can you create a new ticket for this bug? Or I suppose we could hijack this one...
comment:17 Changed 11 years ago by
comment:18 Changed 11 years ago by
Replying to 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
, andNumber("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).
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.