I found an issue with using .data() to access data-* attributes and how it does automatic type conversion. The conversion will break any string that just happens to look like a JavaScript value. A simple example:
HTML:
<div id="foo" data-version="1.0">...</div>
JS:
jsversion = $("#foo").data("version");
jsversion is now the number 1. That is totally wrong if you intend to use that attribute as a string. (I was using it to create a URL where "1.0" is the valid value.)
You can get around this with direct access: $("#foo").attr("data-version") but that's not as much fun. Also, the process is not reversible which is confusing:
$("#foo").data("foo", "1.0");
val = $("#foo").data("foo");
// val is the string "1.0" and not converted to number 1.
// passing in 1.0 vs "1.0" would of course result in 1.
The data() docs say "Note that strings are left intact while JavaScript values are converted to their associated value (this includes booleans, numbers, objects, arrays, and null)". That seems poorly worded since "1.0" is a string just as much as "true", "false", or "null". It should say every attempt is made to convert the string to a JavaScript value otherwise it is left as a string. It would be nice to also mention that if you need literal strings you must use the attr() method mentioned above.
I'd suggest the automatic conversion be removed and let users deal with it as needed. Perhaps add a helper function or alternate data() function to do conversion. The way it works now is intentional and has test cases but I'm unsure what the motivation of this conversion is in the first place? Would it break a common use case to just always treat attributes as strings?
-dave