Mark `document.write()` as obsolete

[zcorpan]

The document.write() API blocks the HTML parser (or rather, <script> blocks the HTML parser because the script might use document.write()) and can cause significant slowness for users (in particular when writing a <script src> which also calls document.write(), and again multiple levels deep). It's also responsible for significant implementation complexity to support (nested invocations of the parser, the need for speculative parsing...).

The spec has this warning:

This method has very idiosyncratic behavior. In some cases, this method can affect the state of the HTML parser while the parser is running, resulting in a DOM that does not correspond to the source of the document (e.g. if the string written is the string "<plaintext>" or "<!--"). In other cases, the call can clear the current page first, as if document.open() had been called. In yet more cases, the method is simply ignored, or throws an exception. Users agents are explicitly allowed to avoid executing script elements inserted via this method. And to make matters even worse, the exact behavior of this method can in some cases be dependent on network latency, which can lead to failures that are very hard to debug. For all these reasons, use of this method is strongly discouraged.

https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#document.write()

Yet, this API is not marked as an obsolete feature. Why not?

MDN doesn't specifically discourage the use of document.write(): https://developer.mozilla.org/en-US/docs/Web/API/Document/write

I'm aware of the following issue that could be argued should block obsoleting document.write():

• Consider adding blocking=render for dynamic import() #7976
• A way to stream content into an element #2142

Are there any other reasons?

(Note that I'm not suggesting that support should be removed. That would not be web-compatible.)

cc @whatwg/html-parser

[domenic]

What are you suggesting specifically by saying "marked as an obsolete feature"?

[zcorpan]

That the IDL

  // dynamic markup insertion
  [CEReactions] Document open(optional DOMString unused1, optional DOMString unused2); // both arguments are ignored
  WindowProxy? open(USVString url, DOMString name, DOMString features);
  [CEReactions] undefined close();
  [CEReactions] undefined write(DOMString... text);
  [CEReactions] undefined writeln(DOMString... text);

and relevant spec text are moved into the Obsolete features section (maybe a new subsection for dynamic markup insertion).

[domenic]

What would the goal of such a move be?

Note also that right now the "Obsolete features" section contains:

• Elements and attributes and their associated HTML interfaces/IDL attributes
• Do-nothing methods and interfaces

This would be the first instance of do-something methods in that section, that aren't related to a non-conforming HTML element.

[zcorpan]

document.all at least is a do-something obsolete API, not associated with a particular element.

The goal is to more clearly be opinionated about the API having the same obsolete status as document.all and have that fact trickle to other documentation like MDN, BCD, and similar.

[zcorpan]

The user-centric goal is to drive down usage and nudge developers towards alternative patterns that don't block the HTML parser, which should make the web less slow for users.

The long-term implementer-centric goal is to drive down usage over time until it's low enough that support can be removed completely. I don't expect this to happen anytime soon, if at all, though.

[domenic]

document.all at least is a do-something obsolete API, not associated with a particular element.

It's not in the obsolete section.

The user-centric goal is to drive down usage and nudge developers towards alternative patterns that don't block the HTML parser, which should make the web less slow for users.

I think MDN might be the best place for that? Or we could consider adding a "this feature is in the process of being removed from the web platform. (This is a long process that takes many years.)" box like we did for document.domain, but it feels a bit early for that.