User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
The above url states that the inline style attribute is of type CSSStyleDeclaration.
Looking up CSSStyleDeclaration we find it states:
While an implementation(user-agent) may not recognize all CSS properties within a CSS declaration block, it is expected to provide access to all specified properties in the style sheet through the CSSStyleDeclaration interface.
Firefox parses out all style declaration's it doesn't recognize and doesn't represent them in the CSSDOM.
Steps to Reproduce:
1.Open a web page that includes an unrecognized style
2.wait for it to render
3.observe the bug :P
try running this:
<div id="ok" style="height:30px; width:200px; unrecognized:value; border:solid 2px Orange"></div>
<input type="button" onclick="AlertFFStyle(document.getElementById('ok'))" value="Alert Style" />
Firefox parses out all style declaration's it doesn't recognize and doesn't represent them in the DOM CSS.
FF "is expected to provide access to all specified properties in the style sheet through the CSSStyleDeclaration interface" even if it "may not recognize all CSS properties within a CSS declaration block".
I ran a thread on Mozillazine for a couple weeks to see what others thought. Here it is:
Yeah, DOM2 Style was written by people who had no idea how CSS works, more or less. The CSS parsing algorithm (as defined in the CSS specification) doesn't allow the behavior this interface requires. Note that this spec has been deprecated in its entirety and a replacement is being worked on.
Pretty sure this is a duplicate, but it's not worth spending the time to find the original, imo.
And just to be clear, the testcase is _really_ showing that we don't keep the original string around. It's not testing the CSSOM at all. We do have a bug covering the original string issue.
(In reply to comment #2)
> And just to be clear, the testcase is _really_ showing that we don't keep the
> original string around. It's not testing the CSSOM at all. We do have a bug
> covering the original string issue.
Just to be clearer W3 does not state what the source of .getAttribute("style") should be, so this could be the CSSOM or the origional string. Logical it could not be the origional string, because dynamically added styles would never show up in .getAttribute("style"), which would be absolutely confusing.
W3 is however clear that getAttribute is a method provided by the DOM. Continuing this train of thought, FF builds the result of .getAttribute("style") from the CSSOM, as is logical, so it is wrong to say, "it's not testing the CSSOM at all" when FF builds the results of this query from the CSSOM.
The fact that we build it from the CSSOM in this particular case is a bug, in practice. None of the other browsers do, until you modify the CSSDeclaration via the CSSOM, as you note. You can verify this trivially in your testcase by inserting |elem.style.display="block"| before your alert. This will in fact cause all browsers to serialize from the CSSOM on getAttribute, and they will all lose the "unrecognized: value" (though that'll be the least of the issues in that case!).
You're right that what exactly getAttribute does is underdefined in the DOM for situations like this, but general consensus seems to be that as long as no object model modification of the attribute's associated object has happened the original string should be returned; future HTML and DOM versions will define this explicitly.
Interesting. I hadn't thought to take my test that far as I was testing each browser I stopped at Firefox when it errored, so your saying you tested in other browsers and each has the same problem as Firefox after assigning a value via the
CSSOM? Its however apparent in Firefox, because of the behavior you describe as a bug is building the style attribute from the CSSOM by difault right?
> your saying you tested in other browsers and each has the same problem
Well, I tested Safari and Opera, and yes. I believe IE does too, last I checked, but I didn't explicitly test it this morning.
> because of the behavior you describe as a bug is building the style attribute
> from the CSSOM by difault