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: Did Not Understand Request
Change Description: no spec change
Rationale:

Surely the script nesting level in this case (when you parse the document.written "</script>") is non-zero, and so you don't go down the path that blocks, you just go down the path that pauses the parser and resumes later when you're not nested. Or am I misunderstanding?

(In reply to comment #1)
> Surely the script nesting level in this case (when you parse the
> document.written "</script>") is non-zero, and so you don't go down the path
> that blocks, you just go down the path that pauses the parser and resumes later
> when you're not nested. Or am I misunderstanding?

The spec says "yielding control back to the caller" in that case, which is what Gecko does, but AFAICT, the spec yields the control back to the caller depending on whether an external style sheet has loaded. This seems bad.

Am I misunderstanding something?

I'm inclined to make document.written inline scripts not check if there's a "style sheet blocking scripts". (I realize that this requires a concept that the spec doesn't currently have: the script element knowing if it was document.written. In Gecko, an element is considered to be document.written, if the '>' character of the start tag was document.written.)

First, http://hsivonen.iki.fi/test/moz/sheet-blocking-script-baseline.php shows that WebKit (incl. Chromium nightly) and Opera don't block even non-document.written parser-inserted scripts until style sheets have loaded.

This leaves only IE and old Gecko as existing behaviors to consider. Gecko's old behavior is not OK, because it makes document.write() return or not return early depending on the loading state of style sheets:
http://hsivonen.iki.fi/test/moz/sheet-blocking-script.html

http://hsivonen.iki.fi/test/moz/sheet-blocking-script3.html shows that script-written sheet can block scripts in IE.

http://hsivonen.iki.fi/test/moz/sheet-blocking-script2.html shows that document.written scripts don't wait for style sheets IE even when another script has already caused document.write to return early. However, these tests also show that IE and Opera put written scripts in the DOM right away, which is *really* weird and not something I want to clone and not something I'd want the spec to say.

My WIP patch for Gecko make Gecko match Chromium nightlies on the number of script elements in the DOM at a given point but makes Gecko match IE on the availability of computed style. (I.e. the patch looks at the document.writtenness of parser-inserted inline scripts instead of checking if document.write is still on the call stack.)

I could be persuaded that I should check whether document.write is on the call stack instead, but this is the story I'm going to go with for now.

(In reply to comment #2)
> The spec says "yielding control back to the caller" in that case, which is what
> Gecko does, but AFAICT, the spec yields the control back to the caller
> depending on whether an external style sheet has loaded. This seems bad.

Well it's not great, sure, but in practice what's the worst that could happen? It's not like the style sheet is going to completely load before the event loop spins anyway, right? I could make this explicit if you like.

Making things depend on where the "<" came from or some such seems like adding yet more hacks to an already particularly large pile of hacks. Given that there's no interop here, I'd really rather just do the minimum required to be compatible with legacy content and have the design be somewhat sane.

Also note that there are no nested event loops here. The parser just blocks and returns control to the event loop until the style sheet is ready, it doesn't nest the event loop (unless you implement it that way, but that would be bad, as you point out).

(In reply to comment #4)
> Well it's not great, sure, but in practice what's the worst that could happen?

When the document's parser is not script-created, the DOM after document.write("<link rel=stylesheet href=...><script>...</script>..."); would be different in HTML5-compliant browsers and in existing Presto, WebKit and Trident (and Gecko 2.0 if Gecko 2.0 if Gecko 2.0 ships in its current state).

When the document's parser is script-created and the script doing the writing pauses between writing a <link> and writing an inline <script>, the DOM after the second write would be network timing-dependent.

> It's not like the style sheet is going to completely load before the event loop
> spins anyway, right? I could make this explicit if you like.

That's a good point for the case where the document's parser is not script-created. It's not such a good point when the document's parser is script-created, but I should test that case in IE before saying more.

You are assuming that data: URLs and cached http: URLs don't go to a loaded state synchronously, though.

> Making things depend on where the "<" came from or some such seems like adding
> yet more hacks to an already particularly large pile of hacks.

ITYM ">". :-)

In Gecko, there's already infrastructure for this. Also, it's already needed in order to ignore document.written charset metas. Presumably, IE has infrastructure, too, since IE varies the blocking behavior for document.write vs. not.

> Given that
> there's no interop here, I'd really rather just do the minimum required to be
> compatible with legacy content and have the design be somewhat sane.

Actually, currently none of the top 4 engines blocks document.written scripts on sheets, so in that sense, there is interop (although Gecko and Trident special-case document.written scripts while WebKit and Presto never block anyway).

Answering Hixie's question from IRC: Gecko defines document.written script as a script whose start tag's ending '>' character came from a document.write argument string. I don't know how IE defines document.written script; I tried to make the behavior equivalent in the case where the entire script is document.written and exact definition is moot.

If you test nightlies, please be aware that there's been a pattern of backing out the relevant patch on Mondays and relanding it on Wednesdays.

I *really* don't want to require that browsers keep track of the provenance of characters in the input stream. That's pretty weird even for the Web.

Do you have some real world sites I could study to understand this problem better?


> Also, it's already needed in order to ignore document.written charset metas.

Why is that required? Are there pages that break if you don't do that?

FWIW, I think I agree with Hixie. It'd be great if we don't have to keep track of what comes from document.write and what comes from the network.

Hrm.. though now I remember that it does have the side effect that you don't really know how much content has been inserted into the DOM if you document.write an inline script.

I.e. the DOM you see after the insert depends on if all existing stylesheets have loaded or not. That is also not very nice.

In Gecko, the provenance tracking comes "for free" from off-the-main-thread parsing already keeping document.written source and network-originating source very, very separate from each other.

Note that this might not remain true as we probably will want to start doing speculative parsing on document.written contents. Apparently other browsers do.

FWIW, I discussed this with Hyatt and Hyatt agrees that blocking on any script that might refer to layout dimensions that might depend on script is the right solution for correctness (that's what the spec does).

I agree that this leads to a situation where document.write() can return early based on network latency.

The decision here seems to be between making the input stream track where data comes from, and making how much document.write() has parsed before it returns depend on network latency.

Further input (especially from browser vendors) is definitely welcome.

I don't have a strong preference. One thing to remember is that this is only a problem for document.write, which is a horrible API anyway.

I can generally live with either behavior here. But I definitely agree that telling written tags apart from network-originated tags potentially introduces a fair amount of complexity into the parser. (Including in gecko if/when we start doing speculative parsing for doc.written stuff)

(In reply to comment #13)
> (Including in gecko if/when we
> start doing speculative parsing for doc.written stuff)

I think it doesn't make sense to fully speculatively parse document.written stuff in Gecko. When document.write blocks, it would make sense to prescan the blocked part for interesting URLs. I'm planning on doing that sometime after reimplementing the sanitizer. I think this will have no effect on the provenance tracking machinery already in place in Gecko.

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: I'm tentatively rejecting this request, on the grounds that everything sucks but at least the behaviour in the spec isn't too magical, and that the only obvious alternative breaks what is currently in an implementation invariant (that the input stream is source-agnostic).

If there are pages that depend on particular behaviour here, that would be good to know. Please don't hesitate to reopen this bug if there is such data.