Interface of returned document with parseFromString(.., "text/xml")

[emilio]

What is the issue with the HTML Standard?

It's not clear from https://html.spec.whatwg.org/#dom-domparser-parsefromstring what the interface of the returned document should be.

We have this test written by @Ms2ger which asserts that the returned document is a Document, but not an XMLDocument. All browsers fail it: https://wpt.fyi/results/domparsing/DOMParser-parseFromString-xml.html

The spec should probably be clarified and the test fixed? Happy to do the later, not sure what the right way of doing the former would be but happy to do so with some guidance.

cc @annevk

[domenic]

This is just a general case of the specification ecosystem not acknowledging the existence of HTMLDocument and XMLDocument, right? whatwg/dom#221

@foolip was looking into this.

[foolip]

Using XMLDocument here seems like clearly the right thing. Fixing everything around the document interfaces at once is a big lift, but maybe the spec could be updated to acknowledge that XMLDocument is real (not an alias) and this specific creation site is fixed?

[annevk]

I think once you acknowledge it is real you will surface the other questions, such as whether it's different from Document in any observable way. So I'm not sure how we can make that change without introducing confusion around that. Especially for implementers of new engines.

[annevk]

I was mistaken, https://dom.spec.whatwg.org/#xmldocument already acknowledges it exists. So all those questions already arise.

Given that I would be okay with updating the return value to be XMLDocument instead.

[emilio]

Is HTMLDocument defined anywhere?

[Ms2ger]

Yeah, https://html.spec.whatwg.org/multipage/nav-history-apis.html#htmldocument

[emilio]

Ah, I grepped for interface HTMLDocument, of course... Thanks!