Open bzbarsky opened 5 years ago
@domenic @annevk
I'd also like to look at this in terms of the priority of constituencies:
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?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.HTMLDocument
, obviously.HTMLDocument
.@cdumez
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.
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.
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.
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.
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.
If this is fixed as I propose, we should also remove the ability to specify [OverrideBuiltins]
on partial interfaces.
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.
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.
Yeah, at 3% there's no way this can be removed, imo. So the only question is where it should live.
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.
Firefox, Safari: HTML documents implement
HTMLDocument
Chrome: HTML Documents implementHTMLDocument
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...
The spec currently has a named getter on
Document
and all documents implementing theDocument
interface, withHTMLDocument
an alias forDocument
.There is no UA that implements that behavior. The implemented behavior is as follows, at this point:
HTMLDocument
; other documents implementDocument
orXMLDocument
, depending. The only thing on theHTMLDocument
interface is the named getter.HTMLDocument
; other documents implementDocument
orXMLDocument
, 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=620f938927faae403375f33d63e2a760a5ce0186In 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]
onDocument
: 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 fromDocument
.Relevant testcases:
undefined
in Chrome and[object HTMLFormElement]
in Safari/Firefox:undefined
in all browsers:[object HTMLFormElement]
in all browsers when served astext/html
andundefined
in all browsers when served astext/xml
:Per current spec, all of those testcases should always alert
[object HTMLFormElement]
.