#10150 closed bug (worksforme)
jQuery.fn.data parses data attributes incorrectly
Reported by: | Owned by: | Rick Waldron | |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | data | Version: | 1.6.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description (last modified by )
See this screenshot of my console output (Chrome 13):
https://skitch.com/grimen/fweb4/developer-tools-http-localhost-3000-admin-tagged-images-debug
I get mixed "CamelCase" with "snake_case" here - I cannot consider this anything else than a bug, neither the dev aside of me. :)
(EDIT: Sorry about that, I was on my mobile and must've slipped and deleted this)
Change History (4)
comment:1 Changed 11 years ago by
Component: | unfiled → data |
---|---|
Description: | modified (diff) |
Owner: | set to Rick Waldron |
Status: | new → assigned |
comment:2 Changed 11 years ago by
Description: | modified (diff) |
---|
comment:3 Changed 11 years ago by
Priority: | undecided → low |
---|---|
Resolution: | → worksforme |
Status: | assigned → closed |
comment:4 Changed 11 years ago by
Thanks for the explanation and samples - appreciated response so quick.
So my view of jQuery always been that it's a layer on top of native (flawed) JS/DOM implementation fixing broken stuff and add compatability. This case is a obvious broken behavior in the native "experience" - it would be hard to find anyone find any good/valid arguments for not fixing this. This makes the wonder what the vision of jQuery really is and also "write less, do more" slogan got more misleading?
jQuery's behaviour matches the intended and expected behaviour of native "dataset" as closely as possible, as seen here:
http://gyazo.com/0cc2d7f4553a1f4a577b667e46b26eff.png
http://jsfiddle.net/rwaldron/Ee8Md/