[w3c/DOM-Parsing] No-namespace element serialized in a namespace if DOM Level 1 xmlns attribute set (Issue #83)

(Likely related to #47 but filing separately, because this is a reverse way of looking at the same problem space.)

https://bugzilla.mozilla.org/show_bug.cgi?id=1763779 gives the following example:

```js
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)
```

In Gecko (where the `XMLSerializer` API originates), this outputs: `"<Plan version='1.0'/>"` That is, the element isn't in a namespace in the DOM, so to keep it not in a namespace in the serialization, the `xmlns` attribute is dropped.

In WebKit and Blink, this outputs: `"<Plan version='1.0' xmlns='http://www.example.com/'/>"`. That is, by retaining the `xmlns` attribute set via DOM Level 1, the element moves into a namespace in the serialization.

I believe the Gecko behavior is correct per the original intent of the semantics of the API, WebKit miscloned the API, and Blink inherited the WebKit bug. However, I don't know what the Web compat implications are at this point.

The spec should be clear about which behavior is intended. If there aren't pressing Web compat reasons to have the WebKit/Blink behavior, I think we should have the Gecko behavior, which is XML-wise correct.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/DOM-Parsing/issues/83
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/DOM-Parsing/issues/83@github.com>