fix: Revert HTMLDocument removal

[ExE-Boss]

See issue #4792, whatwg/dom#221 and whatwg/dom#278

This is already implemented in all major browsers (Firefox, Chrome and Safari).

WPT tests: web-platform-tests/wpt#20403, web-platform-tests/wpt#20676

(See WHATWG Working Mode: Changes for more details.)

---

review?(@annevk, @domenic)

---

💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Jan 15, 2021, 7:59 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

Parsing MDN data...
Parsing...

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[annevk]

Are there tests that show that the getter is only implemented on HTMLDocument? whatwg/dom#221 suggests there are no differences between the document classes.

Where is it defined what ends up creating which type of document?

[ExE-Boss]

I’ve now created the test for this at web-platform-tests/wpt#20403.

[annevk]

To be clear, we need many more tests for this. E.g., web-platform-tests/wpt#20432 cannot use assert_class_string because browsers are quite different in what kind of Document object they use for .svg web-platform-tests resources. Firefox uses XMLDocument, Safari uses HTMLDocument.

And also, the specification side for all those things needs to be crystal clear. A lot of this is "Page load processing model ..." but there's also various other algorithms that end up creating Document objects.

[ExE-Boss]

Well, this is just step 1 that reinstates the interface.

[domenic]

We don't generally do changes that leave the specification in an inconsistent state, so I don't think it would make sense to reinstate the interface without those other changes included.

[ExE-Boss]

Well, I looked through git history all the way back to 2009, and “new HTMLDocument” wasn’t really ever used, it was always “new Document, whose type is "html"”, or “Create a new Document node, and mark it as being an HTML document”, both of which are equivalent.

This means that a Document instance’s inheritance is tied to its type.

---

I don’t really know how to specify that in a sane manner.

[annevk]

I think the ambition was always to have these classes merged as having them separate does not make a whole lot of sense. So now that they're somewhat separate we'll have to say which document creator creates which class.

[ExE-Boss]

Previously, this would’ve resulted in a Document with a default type.