Last Comment Bug 518050 - TundraBlue.com - Non-Standards CSS parsing
: TundraBlue.com - Non-Standards CSS parsing
Status: VERIFIED INVALID
TundraBlue.com - NonStandards CSS par...
: css1, dom0
Product: Core
Classification: Components
Component: DOM: CSS Object Model (show other bugs)
: Trunk
: All All
: P3 major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-21 19:54 PDT by Nathaniel
Modified: 2009-09-22 16:04 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Nathaniel 2009-09-21 19:54:12 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) 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:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)


http://www.w3.org/TR/DOM-Level-2-Style/css#CSS-htmlelementcss-h3 
The above url states that the inline style attribute is of type CSSStyleDeclaration.

http://www.w3.org/TR/DOM-Level-2-Style/css#CSS-htmlelementcss-h3
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.

Reproducible: Always

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>
        <div id="ok" style="height:30px; width:200px; unrecognized:value; border:solid 2px Orange"></div>
    </div>
    <input type="button" onclick="AlertFFStyle(document.getElementById('ok'))" value="Alert Style" />
    <script type="text/javascript">
        function AlertFFStyle(elem)
        {
            alert(elem.getAttribute("style"));
        }
    </script>
Actual Results:  

Firefox parses out all style declaration's it doesn't recognize and doesn't represent them in the DOM CSS.

Expected Results:  
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:

http://forums.mozillazine.org/viewtopic.php?f=25&t=1472475
Comment 1 Boris Zbarsky [:bz] 2009-09-22 06:49:25 PDT
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.
Comment 2 Boris Zbarsky [:bz] 2009-09-22 06:50:53 PDT
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.
Comment 3 Nathaniel 2009-09-22 10:11:43 PDT
(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.
Comment 4 Boris Zbarsky [:bz] 2009-09-22 11:47:19 PDT
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.
Comment 5 Nathaniel 2009-09-22 14:05:38 PDT
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?
Comment 6 Boris Zbarsky [:bz] 2009-09-22 16:04:55 PDT
> 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

Right.

Note You need to log in before you can comment on or make changes to this bug.