-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend document.open/write to non-active documents #2827
Comments
Need tests to see what various browsers do for non-active documents in browsing contexts, at the very least. Also, need to figure out what |
cc @whatwg/html-parser |
Not sure how window matters for |
I'm not a big fan of this streaming parsing hack via |
@jdm Ah. It creates a new Window object, so steps should be same. Doesn't really matter that there is no "physical" window in UI. |
Note, the spec creates a new window global, but not all browsers implement that. We implement it in firefox, but I believe other browsers just reset some state on the current global. |
Yeah, that is #1698. |
Almost certainly not, for documents that don't have a Window to start with. Like I said, needs some careful thought. But yes, it really would be good to have a sane streaming parsing API; people keep asking for that. That might be somewhat orthogonal to whether we support open/write on non-browser-context docs for compat reasons. |
I'd strongly prefer if other browsers fixed their document.open/document.write, and we created a reasonable streaming parser API instead. |
@domenic For continuity, I'd prefer the other browsers to keep the existing That being said, I suspect it might be hard to get the consensus on what streaming DOM parsing would be and |
Screenshots confirming @dvoytenko's claim that all major browsers except Firefox support this based on a trivial test. Filed a chromium bug to track the deviation from the spec here. I don't see an existing UseCounter quantifying the web compat risk of trying to change this, but with (at least) AMP depending on this behavior any measure is likely to be substantial. Since 3 browsers already implement this and there's some not-easily-quantified compat risk to changing it, perhaps we should update the spec / tests to match reality in parallel to whatever people want to do with a parser API? If we want more web compat data confirming this isn't easy to break we could add a UseCounter to chromium then check the HTTP Archive for (non-AMP) sites hitting it during page load, but that'll take a few months to get results for. |
Hi All! Wanted to circle back and follow up on this issue. Is it possible to achieve a consensus and standardize this behavior? Or create an alternative? |
I filed Issue 2993 to take a stab at what asynchronous parsing might look like. |
There is no longer anything fundamental that prevents document.open() from being useful on non-active documents. This also aligns with Chrome, Edge, and Safari. In fact, several projects like AMP already utilize this property as a streaming HTML parser to desirable effects. Fixes whatwg#2827. Tests: web-platform-tests/wpt#12636 Tests: …
There is no longer anything fundamental that prevents document.open() from being useful on non-active documents. This also aligns with Chrome, Edge, and Safari. In fact, some developers already utilize this property as a streaming HTML parser to desirable effect (see #2827). Additionally, use a more appropriate guard for erasing event listeners and handlers on the Window object, as revealed by the tests. Fixes #2827. Tests: web-platform-tests/wpt#12636 Tests: web-platform-tests/wpt#12770
There is no longer anything fundamental that prevents document.open() from being useful on non-active documents. This also aligns with Chrome, Edge, and Safari. In fact, some developers already utilize this property as a streaming HTML parser to desirable effect (see whatwg#2827). Additionally, use a more appropriate guard for erasing event listeners and handlers on the Window object, as revealed by the tests. Fixes whatwg#2827. Tests: web-platform-tests/wpt#12636 Tests: web-platform-tests/wpt#12770
There is no longer anything fundamental that prevents document.open() from being useful on non-active documents. This also aligns with Chrome, Edge, and Safari. In fact, some developers already utilize this property as a streaming HTML parser to desirable effect (see whatwg#2827). Additionally, use a more appropriate guard for erasing event listeners and handlers on the Window object, as revealed by the tests. Fixes whatwg#2827. Tests: web-platform-tests/wpt#12636 Tests: web-platform-tests/wpt#12770
As it stands, the spec defines that
document.open
anddocument.write
should be a no-op for a non-active document. See http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-write:However,
document.open/write
is a convenient (and essentially the only) way to incrementally stream-parse DOM. For instance:Despite the spec, all major browsers except Firefox support this. See https://bugzilla.mozilla.org/show_bug.cgi?id=867102
Alternatives to using this API would be either parse the whole DOM in one go using
DOMParser
or, what most often done on Firefox as a workaround, to parse via a hidden iframe. IMHO both alternatives are significantly worse than expanding the spec to what most of browsers already do.The text was updated successfully, but these errors were encountered: