Side navigation
#12312 closed bug (invalid)
Opened August 15, 2012 06:09PM UTC
Closed August 15, 2012 06:20PM UTC
Last modified August 15, 2012 07:16PM UTC
jQuery's management of the style attribute is lossy when it's re-serialized?
| Reported by: | craig@swixhq.com | Owned by: | |
|---|---|---|---|
| Priority: | undecided | Milestone: | None |
| Component: | unfiled | Version: | 1.8.0 |
| Keywords: | dbr | Cc: | |
| Blocked by: | Blocking: |
Description
I'm surprised to learn that jQuery seems to 'stomp' on the style attribute of DOM elements, reconstructing and replacing it from it's own object model whenever its internals seem to need to. This, as opposed to 'ignoring but keeping' style rules that jQuery doesn't know about. For example, if you want to use -webkit-transform in a .css() call, jQuery ignores it. If you stick it in the HTML, and use a plugin like draggable (jQuery UI), the style attribute gets re-written and your non-native styles (ex: transform) are stripped from the style tag of the dragged element.
It seems to me that jQuery core should allow using it's getters/setters (i.e. .css(property, value)) to be used with any key value pair the author wants. This would make jQuery play nice with other style attributes that it doesn't know about (and there are many). Limiting jQuery's object model to only a subset of supported style properties means jQuery doesn't play nice with other libraries that may inject style attributes into the style tag that jQuery will eventually stomp on whenever it positions an element.
To see what I mean, put style='-moz-transform: rotate(30deg)' on a div and drag it using draggable, or simply use code to trigger a jQuery positioning, like: myDiv.css('position', 'relative') - and you'll see that the -moz-transform was removed from the DOM, presumably because the style attribute was re-serialized using only native jQuery familiar style rules.
I think that when jQuery builds it's object model internally for the style attribute, and rewrites it to the element (serializes it), it should just blindly keep any style attributes that it doesn't know about and assume there's something else in the document that does in fast know about it.
This seems to create a dire choice between using jQuery in a project, or some CSS3 style attributes - both not both. What a terrible choice that is to have to make.
Attachments (0)
Change History (8)
Changed August 15, 2012 06:17PM UTC by comment:1
Changed August 15, 2012 06:20PM UTC by comment:2
| resolution: | → invalid |
|---|---|
| status: | new → closed |
It's stripped in Chrome because it's not valid in Chrome... jQuery has nothing to do with it. http://jsfiddle.net/rwaldron/Pd3af/
Changed August 15, 2012 06:22PM UTC by comment:3
| keywords: | → dbr |
|---|
Changed August 15, 2012 06:49PM UTC by comment:4
This seems to create a dire choice between blocking people who try to visit your site with Chrome, or not caring when -moz-specific style properties are removed. Meh. I guess I'm apathetic.
Changed August 15, 2012 06:59PM UTC by comment:5
Not exactly. You're right that most people wouldn't know if the browser versions of style rules OTHER that the browser you're currently using (ie. stripping -moz if you're viewing in -webkit), however, 2 things:
1) stripping things from the DOM because one library doesn't see the need for it seems to be a dangerous practice because if someone put it there, they put it there for a reason, likely because something else outside your execution context is depending on it.
2) what if you're persisting parts of the DOM? so you manipulate some HTML in a browser, browser strips stuff it thinks is invalid, HTML gets persisted and served to someone else... boom - things are missing.
Part of the beauty of HTML and CSS is that different modules should be able to work on the properties they know about, and ignore (but not modify or delete especially!) the parts they don't know about.
Only in the most traditional use (serving static web pages in a single session with a single browser) is this point moot. But as people starting using browsers as rich clients, that persist, operate more heavily on the DOM and communicate with other browsers, this kind of side effect will crop up more often, IMO.
Changed August 15, 2012 07:04PM UTC by comment:6
Did you even bother looking at my fiddle before soap-boxing? jQuery isn't doing anything, the browser is removing styles it doesn't recognize.
Changed August 15, 2012 07:07PM UTC by comment:7
But rwaldron, should jQuery just stand by idly whilst -moz attributes are slaughtered? Will there be no repercussions for this? I do not wish to live in such a world.
Changed August 15, 2012 07:16PM UTC by comment:8
Ok ok, no need for attitude. rwaldon, Yes I did look at your fiddle and thank you for that, it was helpful. dmethvin's comment took us off in a bit of another direction regardless of whether it was the browser or jquery - but rather the practice of stripping attributes that a browser doesn't recognize, so I continued to express a use case.
I get it, it's not jquery. Thanks.
Sorry, forgot the fiddle:
http://jsfiddle.net/craigfitzpatrick/rakCp/
Inspect the red div in Chrome and see that the '-moz-transform' style piece was stripped, but the '-webkit' part stayed...