Define parser behavior for in-body external stylesheets

[pmeenan]

In-body stylesheets are treated differently by most of the browser engines.

Edge/IE: Parser blocks until stylesheeet is loaded (painting is not blocked)
Firefox: Parser continues, loading stylesheets asynchronously (painting is not blocked)
Chrome/Blink and Safari/WebKit: Parser continues, loading stylesheets asynchronously (painting is blocked until discovered sheets load)

The Edge behavior can be emulated in Firefox by placing a non-empty script tag after the in-body stylesheets since the parser needs to block at a script tag until previous stylesheets have finished. Technically, Blink and Webkit can also emulate the same blocking behavior but it is less useful for developers since all painting is disabled until the sheets have loaded.

[bzbarsky]

The Firefox behavior is the one currently defined in the spec, except for the painting aspect (which is not defined anywhere). So I'm not sure what this issue is asking to define, exactly.

[domenic]

Right, so, it sounds like we should be filing bugs on Edge (with test cases) showing how their parser-blocking behavior is not interoperable with the rest of the web (and is against the spec).

For painting, I'm not sure what to do, or whether to specify it at all. Maybe we could continue adding notes to https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model step 7.3. This one would be something like "Another reason browsers might want to block the rendering is if they have discovered stylesheets that they have not yet loaded, and want to avoid a flash of unstyled content."

[zcorpan]

Chromium is considering changing to be like Edge, though:
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/css$20block/blink-dev/ZAPP8aTnyn0/JURBX5uFCAAJ

[foolip]

@DigiTec, could you help us find a good contact for this issue in Edge?

[foolip]

Does anyone have a high level view of when browsers block painting and for what reasons? I assume it's a non-interoperable pile of heuristics, but it's part of the reality the web developers need to understand and deal with, so specifying it in some way shouldn't be off the table even if it's not observable to the page itself.

[pmeenan]

FWIW, Chrome is open to either the Edge or Mozilla implementations.

The main thing I'm hoping to be able to push forward is native support for the performance optimization where developers inline the critical css in the head (or push with HTTP/2) and load the remaining css later in the body. Right now for that to work they have to use something like loadcss because Blink and Webkit browsers block painting as soon as they discover the in-body css (usually before the viewport has rendered anything).

The Edge behavior has less risk of introducing Flashes of Unstyled Content (FOUC) for any sites that haven't designed for the Mozilla behavior (which is a strong possibility on mobile where Webkit and Blink get most of the attention). It also seems easier for developers to rationalize that "content after an external stylesheet won't paint until the stylesheet has loaded" but the main goal is to just get consistency across browsers so we have something developers can rely on.

[domenic]

If we're looking for consistency across browsers, then the Gecko behavior has the advantage of having the same observable-from-web-code consequences as the current Blink and WebKit behavior. So going with that makes more sense to me.

I guess it's worth finding out if Edge has encountered any compat issues because of their behavior. If so, then probably the Gecko behavior is the better choice. If not, then I guess browsers have some flexibility, and we could try to change everyone to the Edge behavior (despite that being a longer path to interop).

[bzbarsky]

As I pointed out in https://groups.google.com/a/chromium.org/d/msg/blink-dev/QC5iefctcag/dZJZyOz-AwAJ, I think the Edge behavior requires UAs to do a bunch of unstandardized heuristics to get even close to the loading parallelism that Just Happens with the Gecko behavior.... If we wanted to standardize on the Edge behavior, I strongly feel we should standardize those heuristics too, just so new UA implementors have some idea of what they actually need to do to be web-compatible in practice.

[DigiTec]

I'm pretty sure we don't block for in body external stylesheets. At least not that I recall. I could be completely wrong. Let me circle around with some of our older parser folks.

I do know that we increase the progress sink counter. This is used to determine when the load event fires only, but allows everything else to continue. And there were some heuristics added to avoid painting before stylesheets were ready in order to help align us with other browsers. That was done in the original IE code before we forked so it is code we would share.

[pmeenan]

@DigiTec I just stood up a quick test page and at least from the outside it looks like the parser is being blocked.

The test page sets a js timer in the head to fire after 1 second then has a 5-second external css in the body (that turns the background black) and is followed by an empty div. When the timer fires the code looks for the div in the DOM to determine if the parser blocked or not.

Chrome/Safari: Page stays completely blank until the CSS finishes loading then displays that the parser was not blocked (while it didn't paint, the div was present in the DOM)

Firefox: Page displays the progress message immediately, one second later displays the message that the parser did not block and 4 seconds later (when the css loads) changes the background to black.

Edge: Page displays the progress message immediately, one second later displays the message that the parser did block and 4 seconds later changes the background to black.

[chrishtr]

Hi, reviving this thread.

The intent to ship referred to above was approved to ship in Chrome 69 (https://groups.google.com/a/chromium.org/d/msg/blink-dev/QC5iefctcag/HZIo-dIZBAAJ).

I have researched the HTML spec w/@pmeenan and identified a proposed set of patches to it to implement the desired behavior indicated in that Intent:

https://github.com/chrishtr/rendering/blob/master/stylesheet-loading-proposal.md

Note that this proposal goes a bit further than the actual intent, which is for the moment limited to only style sheets in the body.

I have also written up documentation for the motivation of this intent, and results of research into
what the various browsers do here:

https://github.com/chrishtr/rendering/blob/master/stylesheet-loading-behavior.md

I think it would be great to standardize the behavior described in the proposal above. I think it is a clear simplification of behavior, enables progressive rendering without flash-of-unstyled-content via some simple best practices, and cleanly integrates with the existing rendering phase of the event loop processing model.

Regarding performance, @pmeenan and I believe it will be performance-neutral because of the presence of a preload scanner, but will be tracking performance metrics carefully during rollout.

[bzbarsky]

believe it will be performance-neutral because of the presence of a preload scanner

Note that there is no preload scanner in the standard, behavior of the preload scanner is not standardized, and may differ wildly between browsers (and does). So unfortunately, extrapolating any performance results that rely on the preload scanner from one browser to others is complicated.

Put another way, you could have a performance regression in Chrome but not other browsers, or vice versa.