This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Anne told me that monkey patcher should let HTML know about that. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24042#c6 HTML Imports want to prohibit document.write() which is called from scripts in imported documents. This is because script execution timing is undeterministic from the "master" document point of view as imports are loaded concurrently, and location to be written by write() is unreliable. It would be great if HTML spec has some integration point for this purpose.
Why would the location be unreliable? Isn't the parser maintaining the pointer properly? How are you invoking the parser?
(In reply to Ian 'Hixie' Hickson from comment #1) > Why would the location be unreliable? Isn't the parser maintaining the > pointer properly? How are you invoking the parser? Let me clarify how scripts in imported document works. It runs in the context of the "master" document that is the document that has <link>. Think about following example: ----- * index.html <html> <head> <link rel=a.html> </head> <body> ..... </body> </html> * a.html <script> document.write("Hello"); // |document| points index.html </script> ----- In this case, it isn't deterministic that where document.write() puts the text in index.html because the parser for index.html goes ahead regardless a.html is loaded or not. So a.html might be loaded before the <head> in index.html is closed, or it might come after </html>, etc. In other word, index.html and a.html are parsed concurrently by different parsers. This concurrent nature is vital for imports' loading speed. Does this make sense?
It's very deterministic, actually. Assuming that index.html was opened directly (not created using document.open), then the insertion point is undefined, which implies a call to document.open(), which blows away the index.html DOM and aborts its parser, creates a new parser, and you end up with index.html just showing "Hello".
(In reply to Ian 'Hixie' Hickson from comment #3) > It's very deterministic, actually. > > Assuming that index.html was opened directly (not created using > document.open), then the insertion point is undefined, which implies a call > to document.open(), which blows away the index.html DOM and aborts its > parser, creates a new parser, and you end up with index.html just showing > "Hello". Hmm, I was confused or my explanation was wrong. Scripts in import (a.html in the example above) can run while the master document (index.html in the example) is being parsed. It runs without waiting the master being loaded. So timing-wise, there is no difference between a document.write() call from the script in the master document and one from script in an import. Assuming document.write() of the master inserts bytes in the stream (the insertion point is at the end of document under construction), document.write() call from an import should behave in same way. This is why we need a special-casing that bug 24042 outlines. What do I overlook here? Were you assuming that the import parsed after the master is parsed?
It doesn't matter if the document is being parsed or not. When you call document.write() on it, you blow it away. The only times that isn't true are when the whole document was previously created with document.write(), or when you are in inline script running from the parser (which doesn't apply here). (In reply to Morrita Hajime from comment #4) > > So timing-wise, there is no difference between a document.write() call from > the script in the master document and one from script in an import. Agreed, except for the case of an inline script in the master document, in which case there is a difference: the insertion point is defined in that case. > Assuming document.write() of the master inserts bytes in the stream That's a bad assumption. > (the insertion point is at the end of document under construction), Generally speaking, it's not. Usually, the insertion point is undefined.
Thanks for the explanation! I finally got your point. So It seems what I want is a way to bump ignore-destructive-writes-counter for scripts in import. As we plan to merge imports into HTML eventually, it might be fine just to monkey patch it from imports side so far. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#ignore-destructive-writes-counter