Bug 17167 – Failures in fast/dom/Node/initial-values.html

• Component: DOM
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

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.)

[David Kilzer (:ddkilzer)]

See also Bug 17048.

[Julien Chaffraix]

Created attachment 27655 [details]
Fix behaviour of nodeName for prefixed QualifiedName

This fixes "FAIL element.nodeName should be html:pre. Was PRE."

[Eric Seidel (no email)]

Comment on attachment 27655 [details]
Fix behaviour of nodeName for prefixed QualifiedName

Seems fine to me.

[Alexey Proskuryakov]

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.

[Ian 'Hixie' Hickson]

I don't understand the question.

[Alexey Proskuryakov]

> 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.

[Ian 'Hixie' Hickson]

Why should it not become uppercase?

[Alexey Proskuryakov]

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.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

(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.

[Alexey Proskuryakov]

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.

[Eric Seidel (no email)]

Comment on attachment 27655 [details]
Fix behaviour of nodeName for prefixed QualifiedName

Marking r+ again.  At least ap and I agree. :)

[Julien Chaffraix]

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.

[Julien Chaffraix]

Created attachment 27769 [details]
Updated version with better comments and more tests

[Alexey Proskuryakov]

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.

[Julien Chaffraix]

(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.

[Ian 'Hixie' Hickson]

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.

[Eric Seidel (no email)]

(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.

[Julien Chaffraix]

(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.

[Alexey Proskuryakov]

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>.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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).

[Alexey Proskuryakov]

I'm not sure if we should do this, now that Mozilla actively is being actively updated to match HTML5.

[Eric Seidel (no email)]

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.

[Alexey Proskuryakov]

See comment 20, <https://bugzilla.mozilla.org/show_bug.cgi?id=479417>.

[Adam Barth]

Assigning to Eric for resolution.

[Eric Seidel (no email)]

(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).

[Eric Seidel (no email)]

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

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.