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

bzbarsky · 2019-07-22T16:05:41Z

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].

The text was updated successfully, but these errors were encountered:

bzbarsky · 2019-07-22T16:17:05Z

@domenic @annevk

bzbarsky · 2019-07-23T02:43:44Z

Note whatwg/dom#221

bzbarsky · 2019-07-23T02:50:53Z

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 · 2019-07-23T06:53:25Z

@cdumez

domenic · 2019-07-23T14:17:35Z

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 · 2019-07-23T14:34:07Z

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 · 2019-07-23T20:10:05Z

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 · 2019-07-23T20:28:59Z

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 · 2019-07-27T01:45:12Z

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 · 2019-07-29T14:24:45Z

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

bzbarsky · 2019-08-07T21:19:05Z

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 · 2019-08-07T21:25:38Z

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 · 2019-08-07T21:44:55Z

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

ExE-Boss · 2019-11-22T11:28:02Z

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

bzbarsky · 2020-01-10T16:44:06Z

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...

This class is currently not in the spec, but it *is* still in all the major browser engines. For compatibility reasons, let's do what other engines do. There is discussion about bringing HTMLDocument back into specs: - whatwg/html#4792 - whatwg/dom#221

ExE-Boss mentioned this issue Jul 22, 2019

Specify [LegacyWindowAlias=HTMLDocument] on Document whatwg/dom#551

Closed

ExE-Boss mentioned this issue Aug 9, 2019

Use new webidl2js bundle-entry.js feature jsdom/jsdom#2092

Open

ExE-Boss mentioned this issue Nov 22, 2019

fix: Revert HTMLDocument removal #5104

Open

This was referenced Nov 22, 2019

Figure out what to do with XMLDocument whatwg/dom#278

Closed

test(HTMLDocument): Assert that the named property getter is HTML‑only web-platform-tests/wpt#20403

Open

Un-merge Document and HTMLDocument whatwg/dom#221

Open

This was referenced Dec 4, 2019

fix: Use HTMLDocument where applicable whatwg/dom#799

Open

Revert HTMLDocument removal jsdom/jsdom#2744

Open

bzbarsky mentioned this issue Dec 16, 2019

Window named properties shouldn't include some elements in non-HTML documents #5157

Open

annevk mentioned this issue Jan 13, 2020

Move the DOMParser class to HTML #5190

Merged

3 tasks

foolip mentioned this issue Oct 5, 2020

Many notes on api.Document.* refer to the spec-only HTMLDocument alias mdn/browser-compat-data#6839

Closed

awesomekling mentioned this issue Jun 21, 2023

LibWeb: Add HTMLDocument class SerenityOS/serenity#19533

Merged

mrobinson mentioned this issue Jun 19, 2024

Implement window.HTMLDocument servo/servo#32553

Open

5 tasks

annevk added needs tests Moving the issue forward requires someone to write tests interop Implementations are not interoperable with each other labels Oct 8, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

bzbarsky commented Jul 22, 2019

bzbarsky commented Jul 22, 2019

bzbarsky commented Jul 23, 2019

bzbarsky commented Jul 23, 2019

rniwa commented Jul 23, 2019

domenic commented Jul 23, 2019

ExE-Boss commented Jul 23, 2019 •

edited

Loading

rniwa commented Jul 23, 2019

bzbarsky commented Jul 23, 2019

bzbarsky commented Jul 27, 2019

bzbarsky commented Jul 29, 2019

bzbarsky commented Aug 7, 2019

rniwa commented Aug 7, 2019

bzbarsky commented Aug 7, 2019

ExE-Boss commented Nov 22, 2019 •

edited

Loading

bzbarsky commented Jan 10, 2020

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

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

Comments

bzbarsky commented Jul 22, 2019

bzbarsky commented Jul 22, 2019

bzbarsky commented Jul 23, 2019

bzbarsky commented Jul 23, 2019

rniwa commented Jul 23, 2019

domenic commented Jul 23, 2019

ExE-Boss commented Jul 23, 2019 • edited Loading

rniwa commented Jul 23, 2019

bzbarsky commented Jul 23, 2019

bzbarsky commented Jul 27, 2019

bzbarsky commented Jul 29, 2019

bzbarsky commented Aug 7, 2019

rniwa commented Aug 7, 2019

bzbarsky commented Aug 7, 2019

ExE-Boss commented Nov 22, 2019 • edited Loading

bzbarsky commented Jan 10, 2020

ExE-Boss commented Jul 23, 2019 •

edited

Loading

ExE-Boss commented Nov 22, 2019 •

edited

Loading