Failures in fast/dom/Node/initial-values.html As previously mentioned in bug 17060, this test case tests for the exact behavior as spec'd in DOM Level 3. There are a few failures remaining for WebKit. Failures unique to WebKit: FAIL element.namespaceURI should be null (of type object). Was http://www.w3.org/1999/xhtml (of type string). FAIL element.nodeName should be html:pre. Was PRE. FAIL element.namespaceURI should be null (of type object). Was http://www.w3.org/1999/xhtml (of type string) Failures shared by FF3b2: FAIL attr.localName should be null (of type object). Was foo (of type string). FAIL attr.localName should be null (of type object). Was foo (of type string). FAIL doc.namespaceURI should be http://www.w3.org/1999/xhtml (of type string). Was null (of type object). FAIL element.localName should be null (of type object). Was pre (of type string). (FF3b2 fails with "PRE" instead of "pre") FAIL element.localName should be null (of type object). Was pre (of type string). (FF3b2 fails with "pre" instead of "PRE" however.)
See also Bug 17048.
Created attachment 27655 [details] Fix behaviour of nodeName for prefixed QualifiedName This fixes "FAIL element.nodeName should be html:pre. Was PRE."
Comment on attachment 27655 [details] Fix behaviour of nodeName for prefixed QualifiedName Seems fine to me.
HTML5 section about APIs in HTML documents does not have a special case for elements with prefixes - should it? The patch looks right to me, as well.
I don't understand the question.
> I don't understand the question. From HTML5: ---------- For HTML documents, and for HTML elements in HTML documents, certain APIs defined in DOM3 Core become case-insensitive or case-changing, as sometimes defined in DOM3 Core, and as summarized or required below. [DOM3CORE]. This does not apply to XML documents or to elements that are not in the HTML namespace despite being in HTML documents. Element.tagName and Node.nodeName These attributes must return element names converted to uppercase, regardless of the case with which they were created. ---------- In this bug, we discuss a case where nodeName doesn't convert the result to uppercase, even though the element is an HTML element in an HTML document.
Why should it not become uppercase?
As far as I'm concerned, the main reason is that this is what Firefox and Opera do. Also, returning "HTML:PRE" instead of "html:pre" seems to serve no purpose at all - it would create an inconsistency for no practical compatibility reason, as clients that are only aware of HTML semantics would look for "PRE", not "HTML:PRE". I'm deferring to Eric to explain why this is also what DOM 3 Core requires - I couldn't find anything in the spec that directly supported this claim.
Comment on attachment 27655 [details] Fix behaviour of nodeName for prefixed QualifiedName Removing the review flag so this doesn't get landed before we resolve this discussion.
(In reply to comment #8) > I'm deferring to Eric to explain why this is also what DOM 3 Core requires - I > couldn't find anything in the spec that directly supported this claim. I wrote this test *forever* ago (assuming it was even me)... But I find this in the spec: tagName has the value "elementExample". Note that this is case-preserving in XML, as are all of the operations of the DOM. The HTML DOM returns the tagName of an HTML element in the canonical uppercase form, regardless of the case in the source HTML document. That's the discussion of tagName, but it suggests that for xhtml (which is what's under discussion), that case is preserved for all attributes, including prefix, since it's XML.
Actually, the case that is fixed here is in "Element creation using createElementNS on an HTML doc" section of the test, see <http://trac.webkit.org/export/41017/trunk/LayoutTests/fast/dom/Node/initial-values.html>. But I think that compatibility and consistency are sufficient reasons for us to change the behavior.
Comment on attachment 27655 [details] Fix behaviour of nodeName for prefixed QualifiedName Marking r+ again. At least ap and I agree. :)
Comment on attachment 27655 [details] Fix behaviour of nodeName for prefixed QualifiedName Sorry to reply to the discussion this late. I had the same thoughts as Eric about the specification. Document.createElementNS will create an XHTML element per DOM spec (as it splits the localName to fill the prefix which is not done in HTML). To be consistent with the DOM then we also need to have Element.nodeName match the XHTML behaviour. This is also what the other browser are doing. As we do not have a way to know whether an HTMLElement represents internally an XHTML element, the prefix check will correct at least part of the issue (non-prefixed element will continue to fail). Clearing the review flag as I would like to update the test and the code to account for this.
Created attachment 27769 [details] Updated version with better comments and more tests
Comment on attachment 27769 [details] Updated version with better comments and more tests +As we cannot test if an HTMLElement is an XHTML +element, our fix is to check whether it has a prefix and then default +to XML behaviour for nodeName. I don't understand this comment (or a FIXME in HTMLElement.cpp) Where is "XHTML element" defined? In Firefox, HTML elements created by parsing HTML documents (or via createElement) have a null namespace, which is not the case in WebKit and in HTML5. See also <http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsGenericHTMLElement.cpp#327>. Changing the behavior for names with prefixes seemed logical and safe, but saying that XHTML elements should be different from HTML elements is an entirely different thing.
(In reply to comment #15) > (From update of attachment 27769 [details] [review]) > +As we cannot test if an HTMLElement is an XHTML > +element, our fix is to check whether it has a prefix and then default > +to XML behaviour for nodeName. > > I don't understand this comment (or a FIXME in HTMLElement.cpp) Where is "XHTML > element" defined? Maybe it is my interpretation of the DOM & HTML5 specification but an HTMLElement in WebKit can behave in 2 ways as stated in HTML5 and the DOM spec: it either uses the HTML-specific behaviour or the other one (nodeName is an exemple but other methods have the same dual behaviour). As a result, it defines 2 different elements (HTML and XHTML elements). Other browsers can discriminate on the namespace to choose which algorithm to use (as you are pointing out). We cannot because all HTMLElement are in the same namespace. > Changing the behavior for names with prefixes seemed logical and safe, but > saying that XHTML elements should be different from HTML elements is an > entirely different thing. I am not saying that they should be different (internally we would use the same representation). However I am saying that they have a different behaviour with regard to the DOM and it is what is important here. One of the added tests shows that we are choosing the wrong nodeName algorithm for a non-prefixed element created by createElementNS in an HTML document.
In HTML5, it's the document that has the HTML vs XML flag and an element acts as per its document's flag. It isn't done on a per-element basis.
(In reply to comment #17) > In HTML5, it's the document that has the HTML vs XML flag and an element acts > as per its document's flag. It isn't done on a per-element basis. WebKit has an equivalent distinction. document->isHTMLDocument() will tell you if your Document* is really an HTMLDocument* and thus you should be in "html" mode not XHTML mode.
(In reply to comment #18) > (In reply to comment #17) > > In HTML5, it's the document that has the HTML vs XML flag and an element acts > > as per its document's flag. It isn't done on a per-element basis. > > WebKit has an equivalent distinction. document->isHTMLDocument() will tell you > if your Document* is really an HTMLDocument* and thus you should be in "html" > mode not XHTML mode. > Exactly. This is the core of my comments: other browsers do such a distinction on an element level (using the namespace). HTML5 removes the namespace distinction as HTML and XHTML elements uses the same namespace and places the distinction at the document level. However the second change will lead to compatibility bugs (this bug is an example). I am just stating that my change only solves part of our current compatibility issue and that we may prefer to solve it entirely, which means a per-element policy that goes against HTML5. We may also decide that this is just a corner case and just side with HTML5.
FWIW, it seems that Mozilla didn't have a bug about fixing Gecko to use XHTML namespace for HTML elements. I've filed <https://bugzilla.mozilla.org/show_bug.cgi?id=479417>.
It seems that this change still agrees with Opera and Mozilla, but disagrees with HTML5. It's unclear as to if it agrees or disagrees with DOM Core 3. In either case, it's a corner case. I assume this does not break the document.createElement("foo:bar") case? since the real web does that. :) I'm sure we have test cases to cover that though.
Comment on attachment 27769 [details] Updated version with better comments and more tests I'm OK with this. The test should say: +Element creation using createElementNS on an HTML doc: Non-Prefixed Element creation, or HTML Element creation (whichever is more correct).
I'm not sure if we should do this, now that Mozilla actively is being actively updated to match HTML5.
Please cite the mozilla bug numbers, emails, or whatever information you have. :) And feel free to r- the patch. I'm leaving this r+ with intent to have Julien land it until someone else takes decisive action.
See comment 20, <https://bugzilla.mozilla.org/show_bug.cgi?id=479417>.
Assigning to Eric for resolution.
(In reply to comment #25) > See comment 20, <https://bugzilla.mozilla.org/show_bug.cgi?id=479417>. This patch does not change the namespaceURI behavior. IT only changes the nodeName behavior. Going to land this and close the bug (even though there are still other "failures" in this test).
Committing to http://svn.webkit.org/repository/webkit/trunk ... M LayoutTests/ChangeLog M LayoutTests/fast/dom/Node/initial-values-expected.txt M LayoutTests/fast/dom/Node/resources/initial-values.js M WebCore/ChangeLog M WebCore/html/HTMLElement.cpp Committed r44369
Mass moving XML DOM bugs to the "DOM" Component.