Re: Document.createElement: null or HTML namespace?

On 07/10/2014 23:01 , Philippe Le Hegaret wrote:
> On Tue, 2014-10-07 at 14:57 -0400, Philippe Le Hegaret wrote:
>>> 1) Are none of these tests specifically testing createElement on a
>>> non-HTML document?
>>
>> I didn't find one indeed but will send a PR later today to fill the gap.
>
> Here it is:
>   https://github.com/w3c/web-platform-tests/pull/1276
>
> But I ran into troubles...
>
> The DOM spec says that createDocument creates XMLDocument, so I wrote 3
> tests to look at namespaceURI.
>
> 1) createDocument(null, null, null).createElement("A")
>
> everyone agrees it is null.
>
> 2) createDocument("http://www.w3.org/1999/xhtml", "html",
> null).createElement("A")
>
> firefox says null. chrome/safari and opera say
> "http://www.w3.org/1999/xhtml". IE says NamespaceError.
>
> 3) createDocument("http://www.w3.org/2000/svg", "svg",
> null).createElement("A")
>
> firefox and chrome/safari say null. Opera says
> "http://www.w3.org/2000/svg". IE says NamespaceError.
>
> With that in mind, we know what 1) needs to say. What about 2 and 3?

Well, (1) disagrees with the spec but it has the advantage that everyone 
agrees on it. I reckon we should build on that. Also, given the 
disparity in behaviour, I doubt anyone relies on this in the wild 
(though having numbers wouldn't hurt).

IE's behaviour of raising a NamespaceError makes no sense to me. Sure 
enough, serialising a null-namespace element in a namespaced DOM 
requires special care, but that's never been a consideration in the DOM 
(that I know of) and it can be done anyway. I think that we can consider 
it to be just a bug.

For (3), if we discount Presto (which probably shouldn't be a factor 
given its evolution prospects) we have a strong majority towards null, 
unanimity if we take the previous point into account.

For (2), the behaviour from Blink/WebKit strikes me as odd. They are 
basically special-casing the creation of a document that's 
HTML-namespaced to handle createElement() as if it were on a Document 
with the HTML document flag set, while still returning an XMLDocument. 
Is this somehow tied to XHTML support? It's even weirder in that they 
don't perform the lowercasing required on HTML documents and return 
Element instead of HTMLAnchorElement as createElement() on an HTML 
document would. The inconsistency of the decision points me to prefer null.

Also, as a data point, DOM 3 Core would say null.

So all in all I would lean towards systematically using null.

NB: the spec also claims that XMLDocument.load() is relied upon by 
content in the wild. Is that really true? It's broken almost everywhere 
and strikes me a particularly useless.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 8 October 2014 09:17:35 UTC