[Webkit-unassigned] [Bug 17167] Failures in fast/dom/Node/initial-values.html

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=17167





------- Comment #16 from jchaffraix at webkit.org  2009-02-19 14:51 PDT -------
(In reply to comment #15)
> (From update of attachment 27769 [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.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.