Are you writing a user agent that supports scripting but is not supporting document.write()?

I'm planning to plan (sic) to write a user agent. One of my design rules is that the agent may ignore parts of standards, if I deem those parts unnecessarily inelegant. The gist of HTML5 is good enough, but I don't want to be bothered by things like `document.write`. If parts of a website break because its author decided to use obsolete technology, it's their problem.

Even if I weren't planning on bringing yet another UA to the market, I think the way `document.write` works burdens both user agent implementers and HTML5 authors with a lot of extra headaches, while (I assume) so little is gained by supporting it.

I am sure that `document.write` will die some day, and we will all rejoice. The first step to killing this foul-breathed monster is to stop requiring to supporting it, especially on pages that consider themselves to be mature enough to trigger HTML5 no-quirks mode.

For the sake of completeness:

--

PROPOSAL:

* Allow conforming implementations to drop support for both the document.write() and document.writeln() methods on Document DOM objects, currently required by "Dynamic markup insertion".

  - Option 1: the Document interface may lack both `write` and `writeln` methods.
  - Option 2: the `write` and `writeln` methods may throw NotSupportedError exceptions.

* Adjust the specification accordingly, especially where considering "pending parsing-blocking scripts" is required (specifically, the requirements for the parser architecture).

ARGUMENTS FOR EITHER OPTION:

1. These methods are already marked as "considered harmful" in the specification.
2. Dropping support for these functions allows for better software design (both in specification and in code). If support for dynamic insertion is required, the parser can't be properly modularized without maiming its interface.
3. I am assuming that usage in the wild is very limited, especially on websites that are serious about (strict) HTML5 conformance.
4. I am assuming that, ignoring GeoCities-era websites, usage in the wild is now limited to ad and tracking scripts. The scripts are isolated in their own script elements, so the uncaught exceptions won't interfere with other scripts on the page on most UAs.
5. Supporting document.write() also requires pausing the parser when script elements are found. This makes script elements places where the browser must stall rendering and parallel downloads, leading to worse user experience (according to the YSlow team, among others).

ARGUMENTS FOR OPTION 1, AGAINST OPTION 2:

6. Implementers shouldn't have to worry about document.write() and document.writeln() anymore. At all.
7. Feature checks are much easier and more reliable when either the methods work, or the methods are missing.
8. "Object of Document class doesn't have member document.write()" is easy enough to debug.

ARGUMENTS FOR OPTION 2, AGAINST OPTION 1:

9. Exceptions are maybe slightly easier to debug.

ARGUMENTS AGAINST BOTH OPTIONS:

10. Not requiring support for these functions will result in different parsing results.

COUNTER-ARGUMENTS:

11. Against 10: all users of AdBlock Plus (and similar UA features/extensions) already see different parsing results, and as mentioned before, I don't know of any real uses of document.write() besides ad and tracking scripts.
12. Against 10: conformance checking is easier when the subject (i.e. a parser) is guaranteed to terminate successfully.

I patched Firefox to implement option 2 everywhere, shallowly visited the top sites on Alexa (got to 68 before giving up) and came to the following conclusions:

a) I only saw two significantly broken sites: sohu.com's video section didn't work anymore, and live.com didn't load at all.
b) The only 'legitimate' use of document.write() I have seen is conditional loading of scripts. Even if the parser doesn't stall on script elements, I think this can still be solved relatively easily.
c) Some sites have issues loading scripts, but need to update anyway if they want to be HTML5 compliant. This is the case for Paypal, which tries to document.write() links with Javascript URIs. Some web programmers believe you can document.write() on XHTML documents.
d) I think half of the pages I visited used document.write(), but as expected, most of the errors were related to Google Analytics, DoubleClick, SiteCatalyst and other ad/tracking scripts. In a few instances, it was just badly written code.

Consider my proposal changed as follows:

--

PROPOSAL:

* Allow conforming implementations to drop support for the "Dynamic markup insertion" API, consisting of document.open(), document.write(), document.writeln() and document.close().

  - Option 1: the Document interface may lack these methods.
  - Option 2: these methods may raise NotSupportedError exceptions.

* Adjust document.write() to never implicitly call document.open(), but instead raise an exception when the document was not opened for writing.
* Adjust document.open() to raise an exception when the document is still being parsed.
* Allow conforming implementations to not block parsing at script elements.

--

As document.open() has no effect while the document is being parsed, the "Dynamic markup insertion" API will only work when called after the parsing is complete. The third part of the proposal is only there to ensure this can actually be debugged: silent errors are the worst errors.

I also suggest to forbid the usage where document.open() is an alias for window.open().

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: document.write support is needed for compatibility with Existing Content (see http://www.w3.org/TR/html-design-principles/#support-existing-content ) such as this bug report itself. (View Source and you'll find a document.write call in a script on this page!) Therefore, it would be bad to change the description of document.write to be less reality-based.

The reporter says his/her planned to be planned user agent may ignore parts of standards, so it doesn't matter what the standard requires. Thus, document.write doesn't need to be made optional in the standard.

Note that the standard allows user agents to support the XML serialization without supporting the HTML serialization, so if you wish to ignore inelegant parts, you may ignore the entire HTML serialization and just implement the XML serialization. However, note that when scripting is enabled, processing the XML serialization involves blocking the parser, too, so you don't get rid of the concept of parser-blocking scripts just by not implementing document.write.

Regarding point 5 in comment 3: It's possible to support document.write without stalling parallel downloads. I've implemented it. And documented how to do it: https://developer.mozilla.org/en/Gecko/HTML_parser_threading