Skip to content

No-namespace element serialized in a namespace if DOM Level 1 xmlns attribute set #83

Open
@hsivonen

Description

@hsivonen

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

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions