We should probably reinstate HTMLDocument, with a named getter, in the spec

bzbarsky commented 5 years ago

The spec currently has a named getter on Document and all documents implementing the Document interface, with HTMLDocument an alias for Document.

There is no UA that implements that behavior. The implemented behavior is as follows, at this point:

Firefox, Safari: HTML documents implement HTMLDocument; other documents implement Document or XMLDocument, depending. The only thing on the HTMLDocument interface is the named getter.
Chrome: HTML Documents implement HTMLDocument; other documents implement Document or XMLDocument, depending. The named getter is implemented only for HTML documents, and not even for all of those; see https://bugs.chromium.org/p/chromium/issues/detail?id=594008 for example. In general, the thing Chrome does matches no possible interpretation of the spec and can't be expressed in Web IDL; it's also generally considered buggy by the Chrome engineers, based on comments like https://cs.chromium.org/chromium/src/third_party/blink/renderer/bindings/core/v8/local_window_proxy.cc?l=523-526&rcl=620f938927faae403375f33d63e2a760a5ce0186

In practice, that means that XML documents returned from XHR's responseXML do not implement the named getter in any browser. Adding the named getter to those would be a pretty serious compat risk due to the [OverrideBuiltins] on Document: attribute values inside the document could then cause APIs to be overridden on the document object, where they are not overridden in any browsers right now.

It seems to me that the simplest path to interop and web compat here is to converge on the Firefox/Safari behavior: reintroduce HTMLDocument with a named getter on it and remove the named getter from Document.

Relevant testcases:

Alerts undefined in Chrome and [object HTMLFormElement] in Safari/Firefox:

<!doctype html>
<script>
var url = 'data:text/html,<html xmlns="http://www.w3.org/1999/xhtml"><form name="x"/></html>';
var xhr = new XMLHttpRequest();
xhr.open("GET", url);
xhr.responseType = "document";
xhr.onload = function() {
alert(xhr.responseXML.x);
};
xhr.send();
</script>

Alerts undefined in all browsers:

<!doctype html>
<script>
var url = 'data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><form name="x"/></html>';
var xhr = new XMLHttpRequest();
xhr.open("GET", url);
xhr.responseType = "document";
xhr.onload = function() {
alert(xhr.responseXML.x);
};
xhr.send();
</script>

Alerts [object HTMLFormElement] in all browsers when served as text/html and undefined in all browsers when served as text/xml:
```
<html xmlns="http://www.w3.org/1999/xhtml">
<form name="x"></form>
<script>
alert(document.x);
</script>
</html>
```

Per current spec, all of those testcases should always alert [object HTMLFormElement].

bzbarsky commented 5 years ago

@domenic @annevk

bzbarsky commented 5 years ago

Note https://github.com/whatwg/dom/issues/221

bzbarsky commented 5 years ago

I'd also like to look at this in terms of the priority of constituencies:

Users: Really don't care about any of this, as long as web pages don't break.
Authors: Do authors want the named getter on Document? Do they want it at all, apart from keeping existing pages working? I agree that if there is only one type of document that's a bit less confusion for authors, but does it outweigh the drawbacks of the nasty named getter with its shadowing behavior on everything?
Implementors: it's strictly less work to not get rid of the existing HTMLDocument separate from Document for all three implementations. Blink's behavior would be easier to fix to follow a spec with a named getter on HTMLDocument than one with a named getter on Document, as far as I can tell.
Specifiers: It's more work to switch back to having HTMLDocument, obviously.
Theoretical purity: Better to not have HTMLDocument.

rniwa commented 5 years ago

@cdumez

domenic commented 5 years ago

I think authors would prefer the simpler model of a single Document type with aliases. I know I was very confused by this mess in my web author days.

That said, I can easily be persuaded that at this point, the benefit to authors is small enough, that we should weigh implementers higher than authors/specifiers/theoretical purity.

ExE-Boss commented 5 years ago

I still think that the named getter is a legacy mistake.

Sadly, we probably can’t just get rid of it, but we could maybe at least standardise Chrome’s behaviour.

That said, it looks to be a feature that seems to be completely undocumented outside of the DOM specification, and I don’t know how much it’s actually being used.

rniwa commented 5 years ago

Sadly, we probably can’t just get rid of it, but we could maybe at least standardise Chrome’s behaviour

I don't see how having an inconsistent behavior on HTMLDocument like Chrome does is more helpful to authors. Having consistency is good. Every inconsistency we introduce into the Web platform is yet another thing author has to deal with.

bzbarsky commented 5 years ago

Hmm. Github seems to have lost my comment... Yes, the named getter is a legacy mistake. As far as usage, there have been a bunch of tutorials and copy/paste stuff that relied on it working, even though it didn't explicitly call out its existence.

That said, adding use counters for the named getter in browsers would not be hard. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1568310 to do that for Firefox.

bzbarsky commented 5 years ago

Only two days worth of data so far, so it's a bit preliminary, but https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-07-25&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F70&measure=USE_COUNTER2_HTMLDOCUMENTNAMEDGETTERHIT_PAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-07-24&table=0&trim=1&use_submission_date=0 shows about 3% of pageloads returning something other than undefined from the named getter.

bzbarsky commented 5 years ago

If this is fixed as I propose, we should also remove the ability to specify [OverrideBuiltins] on partial interfaces.

bzbarsky commented 5 years ago

Only two days worth of data so far, so it's a bit preliminary

We've got well over a week of data now, and for the last 7 days it's stable at about 3% of pageloads, on the Firefox nightly channel. The probe hasn't made it to beta yet, but honestly I don't expect it to be much different there.

rniwa commented 5 years ago

We've got well over a week of data now, and for the last 7 days it's stable at about 3% of pageloads, on the Firefox nightly channel.

3% is really high. For a comparison, the last time I checked, attachShadow (which is a function one must call to use shadow DOM) was used on only ~1.5% of page loads according to Chrome Platform Status. So named getters on document is used roughly twice as more frequently than the entirely of shadow DOM API.

bzbarsky commented 5 years ago

Yeah, at 3% there's no way this can be removed, imo. So the only question is where it should live.

ExE-Boss commented 4 years ago

Well, I believe that it should live on HTMLDocument, which is why I opened #5104 and https://github.com/web-platform-tests/wpt/pull/20403 to do this.

bzbarsky commented 4 years ago

Firefox, Safari: HTML documents implement HTMLDocument Chrome: HTML Documents implement HTMLDocument

It's a little more complicated. Firefox implements HTMLDocument for text/html and application/xhtml+xml, whereas Safari and Chrome only do it for text/html, apparently...

whatwg / html

We should probably reinstate HTMLDocument, with a named getter, in the spec #4792