Serializing outerHTML of an HTML node that got adopted by an XML document

[geofft]

In the course of figuring out a workaround to #84, I decided to looked for some other mechanism that does actually set the "require well-formed" parameter to true when serializing.

My reading is that outerHTML's getter runs the fragment serializing algorithm with the "require well-formed" parameter set to true, and the fragment serializing algorithm specifically produces an XML serialization if the node document is XML, and serializing an XML node serializes its children by specifically calling XML serialization, preserving the "require well-formed" flag in the recursive call. That is, getting .outerHTML on a XML node with an unserializable child should fail. (Note also that outerHTML is documented as "In the case of an XML document, throws a "InvalidStateError" DOMException if the element cannot be serialized to XML.")

But if you try the following code

const xmlDoc = document.implementation.createDocument(null, null); 
const rootNode = xmlDoc.createElement("root");
xmlDoc.appendChild(rootNode);
const childNode = document.createElement("child");
childNode.innerHTML = '<meta property="og:description" content="I forgot to "escape" this value">';
xmlDoc.adoptNode(childNode);
rootNode.appendChild(childNode);
const result = rootNode.outerHTML;
console.log(result);
console.log(new DOMParser().parseFromString(result, "text/xml").querySelector('parsererror').innerHTML);

in Firefox, Safari, and Chrome, .outerHTML does not throw and returns not-well-formed XML, and you can see that DOMParser does not like it.

Am I missing something in the specification that provides for this behavior? I realize I'm doing something tricky by adopting an HTML element into XML, but my reading of the adoption process is that it change's the node's node document, and this is what triggers serializing as XML. In any case, I'm getting .outerHTML of an actual XML node, which should recursively serialize as XML.

I mentioned this over at https://bugzilla.mozilla.org/1914813 and was told that even if this is an implementation bug but all the major implementations happen to do the same thing, the right thing to do is to update the spec, so I'm filing this here.