1763779 - JavaScript XMLSerializer is removing xmlns attributes

Status: UNCONFIRMED

(Core :: DOM: Serializers, defect)

Description

[Luca Jung]

Steps to reproduce:

The behavior of the JS engine in Firefox is different from that in Chrome. Apparently Firefox seems to remove xmlns attributes during XML serialization.

Steps to reproduce -> Just execute the following lines:

let doc = document.implementation.createDocument("", "", null);
let xmlEl= doc.createElement("Plan");
xmlEl.setAttribute("version", "1.0");
xmlEl.setAttribute("xmlns", "http://www.example.com/");
doc.appendChild(xmlEl);
let outputString = new XMLSerializer().serializeToString(doc.documentElement);
console.log(outputString)

Actual results:

The code produces the following output: <Plan version="1.0"/>
Apparently the xmlns attribute is not part of the output.

Expected results:

In Chrome the code produces the following output: <Plan version="1.0" xmlns="http://www.example.com/"/>
In my opinion this is also correct, because all added attributes are also included in the output.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Robert Longson [:longsonr]]

If you want to create an element in a custom namespace you must use createElementNS and not createElement so

let xmlEl= doc.createElementNS("http://www.example.com/", "Plan");

Then you don't need the setAttribute call.

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Is Chrome's behavior expected here?

Comment 4

[Henri Sivonen (:hsivonen)]

I think Chrome's behavior isn't expected in the sense that, IIRC, this is an API that Gecko introduced and then WebKit implemented differently before the Blink fork, so Chrome got the WebKit behavior that allows DOM Level 1 manipulation of namespaces while Gecko requires DOM Level 2 namespace-awareness. The spec seems to support the WebKit/Blink behavior. It's unclear to me what the justification for the spec being the way it is is. It seems the spec comes from the era when Microsoft was aligning Trident/EdgeHTML to be more Web-compatible, so perhaps the spec is justified in terms of Web compat. Hard to know now.

Comment 5

[Sean Feng [:sefeng]]

I think we want probably file a spec issue to clarify this Henri?

Comment 6

[Henri Sivonen (:hsivonen)]

Filed as https://github.com/w3c/DOM-Parsing/issues/83