I think we'll stay with what we have.

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

Duplicate of #7579.

This seems ok to you?

http://jsfiddle.net/rKnFu/

I'm trying to store a number as hex, but jquery assumes I really meant exponential notation? WTF?

Use attr()

I'm honestly not trolling here, but this is pretty much like what PHP does ; automatic type-guessing without a proper way to tell it how to do it. IMHO it's bad

At least in JSON we have a syntax to indicate the type.

I'd like to have .data() to always return a string and have convenient helpers to easily/manually change the type if needed.

Using .attr() is a good replacement for .data() in many cases, especially if you want a read/write behavior and expect to reflect the value in the "real" html attribute.

But some times, you want the benefit of .data(), but this type mess.

I'd like to have .data() to always return a string and have convenient helpers to easily/manually change the type if needed.

You mean if someone set a Boolean using .data("visited", false) we would return the string "false" for .data("visited")? Go think about the havoc that would cause to existing code.

As the submitter of this ticket, I do NOT agree with what Jeremy just said.

I think that .data() should *always* return what you put into it. But, any element attribute which was written in HTML, not via JS dom manipulation, ie: <div data-foo="">, should return String since casting is dangerous and unreliable in this case. There is no type information that can be assumed, other than String, and existing behavior cannot work correctly for all cases.

fyi, my blog posting on this has received over 10k views. This is clearly an issue for a lot of people. It would be good if the JQuery community took it more seriously, but I'm not holding my breath.

latchkey, the majority of the confusion comes from the expectation that .data() is used ONLY to get and set data- attributes. Unfortunately, since the method predates HTML5 and data- attributes, it has different semantics and capabilities. If you look at the dup ticket #7579 referenced here, we tweaked things a bit in 1.8.0 to only convert something to a number if it wouldn't change the representation, so data-number="1.80000000" will stay a string since it would otherwise clip the zeroes.

I don't think there is anything we can do to meet everyone's expectations yet avoid breaking code. In any case, a closed duplicate ticket isn't a good place to discuss.

I've got a case where a large number is stored as a data- attribute in the HTML. When you fetch the value using $.data, the coercion is buggering up the number and it breaks my code because I'm not getting back EXACTLY what has been put into the HTML.

For example:

<tr data-id="201319611370584515">etc</tr>

When I call .data to fetch that value, I get the integer value 201319611370584500 back and because I need that id to match elsewhere of course it fails.

If I place an alpha character at the beginning of the attribute, for example data-id="x201319611370584515", then I get back exactly what I put in there.

It's beyond me how this behaviour can be considered justifiable when you are dealing with a data format that is patently not typed (HTML). I can't see any rationalisation for it returning a different value to what actually appears in the HTML.

I guess I will use .attr but I think this peculiar behaviour with large numbers needs to be explicitly spelled out in the documentation (or even better fixed) because I had to Google this issue and came upon this bug by way of the blog post mentioned above after scratching my head for over an hour trying to work out what the hell was going on.

Replying to [comment:9 anonymous]:

I've got a case where a large number is stored as a data- attribute in the HTML. When you fetch the value using $.data, the coercion is buggering up the number and it breaks my code because I'm not getting back EXACTLY what has been put into the HTML. For example: <tr data-id="201319611370584515">etc</tr> When I call .data to fetch that value, I get the integer value 201319611370584500 back and because I need that id to match elsewhere of course it fails. If I place an alpha character at the beginning of the attribute, for example data-id="x201319611370584515", then I get back exactly what I put in there. It's beyond me how this behaviour can be considered justifiable when you are dealing with a data format that is patently not typed (HTML). I can't see any rationalisation for it returning a different value to what actually appears in the HTML. I guess I will use .attr but I think this peculiar behaviour with large numbers needs to be explicitly spelled out in the documentation (or even better fixed) because I had to Google this issue and came upon this bug by way of the blog post mentioned above after scratching my head for over an hour trying to work out what the hell was going on.

This is already fixed, please upgrade your version of jQuery.

JavaScript numbers are IEEE standard 754, double-precision binary floating-point 64-bit numbers. This means that only even numbers greater then (2^53) are representable. jQuery had enough bug report/complaints about larger numbers (eg. 201319611370584515) being rounded that the only solution was to use a string to represent data values that were not representable as numbers. This way you get the actual value, despite the type being incorrect.