only try to normalize the units to px on IE if it's not set on style attribute#2417
only try to normalize the units to px on IE if it's not set on style attribute#2417gonchuki wants to merge 1 commit intomootools:masterfrom
Conversation
…on the style attribute
|
Right, but this issue is what was brought up in: #2337 (comment) To reiterate.. should getStyle return the css definition? Here's a thought: var CSSStyle = function(element, value){
this.element = element;
this.value = value;
};
CSSStyle.prototype.toString = CSSStyle.prototype.valueOf = function(){
return this.value;
};
CSSStyle.prototype.toInt = function(){
// if not in px form, then some how compute the value
};Trying to keep compat with this toValue and toString magic, but I'm sure it's not 100%. |
|
The CSS definition as in what the CSS stylesheet has instead of the manually set That being said, if you inspect this patch it is to actually do less mangling on IE as we were doing too much. The code in that block normalizes cases where IE returns the value on the stylesheet on a |
|
+1 for doing less -> see #2328 |
|
It has already been changed: https://github.com/mootools/mootools-core/blob/master/Source/Element/Element.Style.js#L169 I'll merge the test. |
|
Scratch that... |
After reading this StackOverflow question I noticed the IE normalization code on
getStylewas also overriding a style that was directly set on the element, so if for example you set a style on a non-px based unit, a later getStyle would mangle that unit back into px.This patch simply avoids running the normalization if the return value was directly set on the element, so that IE can behave just like any other browser.
I know @ibolmo is running a drive to refactor this on #2414 but this is just another thing he will need to take into account when refactoring (adds 2 tests) and improves our robustness right now.