Intent to Implement and Ship: Stylesheets activated after the body is started do not block paint

650 views
Skip to first unread message

Patrick Meenan

unread,
May 26, 2016, 1:45:34 PM5/26/16
to blink-dev
pme...@chromium.org None External stylesheets in the body of the document or that get activated after the body has started to be parsed will no longer block paint. The parser will still block at a script tag until all prior stylesheets have loaded, including those in the body.

This change was implemented in Chrome 52 behind the Experimental Web Platform Features flag. This change allows for performance optimizations that the web performance community has been advocating for for a long time where developers can split their css between critical and below-the-fold and inline the critical css while loading the below-the-fold css after the above-the fold content. In principle that allows for rendering the critical part of the page with no additional round trips but in practice Blink blocks all rendering, even of the above-the-fold content as soon as it discovers the lower late-body css (usually well before it has painted any content at all).

There are Javascript hacks to work around the render blocking like loadcss and the proposed change matches the existing Firefox behavior (with Edge providing a slightly different variation but still allowing paint).
Firefox: Shipped Edge: No public signals Safari: No public signals Web developers: Strongly positive There is minimal risk of breaking any existing content. At worst there will be a flash of unstyled content for sites that have external sheets in the body. Those same sites will already encounter FOUC's with Firefox. None Yes None
crbug for paint-blocking issue: http://crbug.com/481122 https://www.chromestatus.com/features/5696805480169472 Yes

Chris Harrelson

unread,
May 26, 2016, 1:57:33 PM5/26/16
to Patrick Meenan, blink-dev
Have you considered issuing a console warning for at least one release that this behavior will change soon? I'm not as sure as you that there won't be a lot of websites with somewhat more flashing, though I agree it seems they won't actually break.

Also, what is the status of spec'ing this behavior and feedback from other browser vendors?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Patrick Meenan

unread,
May 26, 2016, 2:05:44 PM5/26/16
to Chris Harrelson, blink-dev
Console warning is easy enough to implement since the code to track if a sheet would be impacted by the change is all in one place.  I can also query the Alexa top-500k in Big Query from the HTTP Archive and get a sense for how often it shows up in the static HTML but that would only catch landing pages.

As far as spec goes, I'm not aware of any progress on it but the Firefox and Edge implementations are different enough that one of them would have to change to get consistency.  Feedback from Firefox on my earlier intent to implement the parser-blocking behavior of edge was positive though with a preference to implement Firefox's behavior.  There was no public opinion from Edge.  This is a necessary first step if we end up deciding to converge on the Edge behavior instead of the Firefox behavior.

Elliott Sprehn

unread,
May 26, 2016, 2:09:12 PM5/26/16
to Patrick Meenan, Chris Harrelson, blink-dev
On Thu, May 26, 2016 at 11:05 AM, 'Patrick Meenan' via blink-dev <blin...@chromium.org> wrote:
Console warning is easy enough to implement since the code to track if a sheet would be impacted by the change is all in one place.  I can also query the Alexa top-500k in Big Query from the HTTP Archive and get a sense for how often it shows up in the static HTML but that would only catch landing pages.

As far as spec goes, I'm not aware of any progress on it but the Firefox and Edge implementations are different enough that one of them would have to change to get consistency.  Feedback from Firefox on my earlier intent to implement the parser-blocking behavior of edge was positive though with a preference to implement Firefox's behavior.  There was no public opinion from Edge.  This is a necessary first step if we end up deciding to converge on the Edge behavior instead of the Firefox behavior.


Why is this a first step? It seems like switching directly to the Edge behavior doesn't have any risk associated with making pages FOUC. Shipping async sheets does have risk of making a bunch of blinking content. :) 

- E 

Rick Byers

unread,
May 26, 2016, 2:10:33 PM5/26/16
to Patrick Meenan, Chris Harrelson, blink-dev
Is there at least an issue filed in some W3C or WHATWG GitHub for the fact that the spec doesn't reflect implementations here?

Getting some data of the impact either from HTTPArchive or (better) UseCounters would be good.  If you're going to output a console warning anyway, you might as well make that a deprecation and consult the UMA data before changing it.  You believe you can tell reliably at runtime when this change will cause a FOUC?

Patrick Meenan

unread,
May 26, 2016, 2:14:49 PM5/26/16
to Rick Byers, Chris Harrelson, blink-dev
Reliably at runtime I can detect when a script-blocking stylesheet is activated after the body has started.  I can't detect if that will trigger a FOUC because there's no way to tell if the sheet includes any styles relevant to content in the viewport.  At best I can over-count and detect cases where it COULD cause a FOUC that wouldn't have been there before but not necessarily that it WILL cause one.

Patrick Meenan

unread,
May 26, 2016, 2:21:09 PM5/26/16
to Elliott Sprehn, Chris Harrelson, blink-dev
Implementation is a necessary first step.  The Edge behavior of blocking the parser still requires that we not block painting while the parser is blocked.  Actually shipping isn't necessary if we prefer to jump to the Edge behavior and ship that.  The Edge behavior doesn't eliminate the possibility of FOUC.  Anything in the DOM before the stylesheet was referenced that contains elements that will be styled by the later sheet will still flash.  It does prevent cases of FOUC for any content referenced after the sheet.

If we'd rather ship the Edge behavior then I can leave this behind a flag while we work on that.  That said, my first run at pausing the parser for sheets (and HTML imports which would also need to be paused after) was...challenging.  The state tracking for the parser and token streams have some edge cases which are riskier (for me) to be poking at.

Rick Byers

unread,
May 26, 2016, 2:28:46 PM5/26/16
to Patrick Meenan, Chris Harrelson, blink-dev
On Thu, May 26, 2016 at 2:14 PM, Patrick Meenan <pme...@google.com> wrote:
Reliably at runtime I can detect when a script-blocking stylesheet is activated after the body has started.  I can't detect if that will trigger a FOUC because there's no way to tell if the sheet includes any styles relevant to content in the viewport.  At best I can over-count and detect cases where it COULD cause a FOUC that wouldn't have been there before but not necessarily that it WILL cause one.

Makes sense, thanks.  So the only thing I'd caution against then is dramatically over-warning.  Eg. if you're over-counting by 10x then a warning message will probably do more harm (deprecation warning blindness / wasted effort) than good.  In which case we should still have a UseCounter to track the upper bound of risk, but ship without a warning but (as always) keep a close eye on user feedback in beta etc.

Patrick Meenan

unread,
May 26, 2016, 2:51:03 PM5/26/16
to Rick Byers, Chris Harrelson, blink-dev
As far as specs go, any recommendations where I should poke for specs about painting behavior?

There are a few WHATWG specs that get close and touch on parts of the behavior but none of them talk about rendering/painting (even for head sheets):
* External stylesheets are "body-ok" (allowed in the body)
* Styles that block scripts are spec'd
* Fetching of the sheets are spec'd
* The rendering spec doesn't appear to touch on when or how to paint
* I couldn't find anything relevant in the csswg spec

On Thu, May 26, 2016 at 2:10 PM, Rick Byers <rby...@chromium.org> wrote:

Philip Jägenstedt

unread,
May 27, 2016, 8:14:10 AM5/27/16
to Patrick Meenan, Ian Hickson, Rick Byers, Chris Harrelson, blink-dev
Is this change in any way observable to web content? Blocking the parser would be like Edge does would be, right?

I ask because however observable to end users, if it's not observable to scripts at all, then it's unsurprising if no spec touches upon this and I'm not sure which spec would.

Hixie, do you remember if you ever put anything in HTML related to painting?

Ian Hickson

unread,
May 27, 2016, 1:29:46 PM5/27/16
to Philip Jägenstedt, Patrick Meenan, Rick Byers, Chris Harrelson, blink-dev
I think this is one of those quality-of-implementation issues. I doubt any spec talks about it.

Patrick Meenan

unread,
May 27, 2016, 1:39:22 PM5/27/16
to Ian Hickson, Philip Jägenstedt, Rick Byers, Chris Harrelson, blink-dev
It should be completely transparent to scripts and unlikely to be observable from code.

I'm not 100% sure IE actually blocks the parser, they may just prevent the new nodes from getting added to the render tree if they are discovered after and external stylesheet (for blink, mirroring the behavior would be easiest if we actually paused the parser progress.  Even then, observability from code would be racy.  Any new script tags would still block the parser so it would take an existing script running a RAF or timer loop checking the DOM for progress and it would have to know that the HTML had actually arrived to the parser (maybe if it was document.written).

Elliott Sprehn

unread,
May 27, 2016, 11:42:36 PM5/27/16
to Patrick Meenan, Chris Harrelson, Rick Byers, Ian Hickson, Philip Jägenstedt, blink-dev

Edge (and I'm pretty sure IE) actually block the parser. This is observable by running a setTimeout loop and observing the DOM. See the snippets I posted on this bug.

The WebKit/Blink behavior today is confusing since we do some funny things around the first forced layout. The doc on the FOUC sanity meta bug describes this.

Long term we should either be async in the body or block the parser. I think the Edge behavior is least likely to break content and make it blink though. :)

Philip Jägenstedt

unread,
May 30, 2016, 9:15:52 AM5/30/16
to Elliott Sprehn, Patrick Meenan, Chris Harrelson, Rick Byers, Ian Hickson, blink-dev
Patrick, have you had a discussion with the relevant people for other engines to figure out what behavior to try converging on?

I guess that blocking the parser makes it easy to order the markup to get the intended behavior, but are there worthwhile things that could be achieved if there was no blocking at all?

Patrick Meenan

unread,
May 30, 2016, 3:51:38 PM5/30/16
to Philip Jägenstedt, Elliott Sprehn, Chris Harrelson, Rick Byers, Ian Hickson, blink-dev
I don't know the relevant people to chat with about it for the other engines.  I'll file an issue on the whatwg html tracker to start discussion on the blocking of the parser.  From the sounds of it, the "when to paint" part doesn't currently fall into any of the groups' domain.

The only thing that comes to mind with no blocking at all is you could get a little more control over blocking though it's more implicit and relies on the fact that the parser will block at the next script tag.  You could emulate the current Edge behavior by putting a script tag after in-body external sheets but that does feel a bit bizarre.  By not blocking you could have a collection of in-body sheets followed by a script tag and have the parser process all of them and then block until they all finish.  Only real benefit I can think of for that case though is if the sheets @import other sheets.  By loading them async the parser will not get stuck serializing the imports (which are largely not handled by Chrome's preload scanner currently).  That's a pretty edge case of an edge case though.

Whatever the behavior there is likely to be some impact on the behavior for HTML imports as well.  Blocking the parser for css will probably also mean blocking the parser for imports and the dependency serializing becomes a bigger issue there.

Patrick Meenan

unread,
May 30, 2016, 4:00:56 PM5/30/16
to Philip Jägenstedt, Elliott Sprehn, Chris Harrelson, Rick Byers, Ian Hickson, blink-dev

Elliott Sprehn

unread,
May 30, 2016, 5:15:57 PM5/30/16
to Patrick Meenan, Chris Harrelson, Rick Byers, Ian Hickson, Philip Jägenstedt, blink-dev

I don't think we should worry too much about the current html imports. The only reason they need to block painting is because of the behavior where imports can apply stylesheets. That behavior will never be added to the future html modules (which can't apply styles and are deferred by default).

We should continue with the FOUC avoidance sanity plan:
- don't block the parser until we undefer commits. This code is now in core so it's easy to connect to the parser.
- never block the parser on html imports
- don't undefer commits until parser inserted imports or sheets that were inserted before the body are done loading.

That will avoid FOUC, keep the parallelism for all html imports, and greatly simplify the system. It also shouldn't have any FOUC risks like making all sheets async.

Patrick Meenan

unread,
May 31, 2016, 9:46:27 AM5/31/16
to Elliott Sprehn, Chris Harrelson, Rick Byers, Ian Hickson, Philip Jägenstedt, blink-dev
Discussing it on the whatwg github issue but as Boris points out, the Edge behavior is against the current spec which calls for link tags to not block the parser and doesn't treat head/body differently.  I'll get a usage counter added and work on an implementation for the Edge behavior for the parser in case the spec moves in that direction.  I'm also trying to reach out to the Webkit team to see if they would be comfortable implementing either behavior.

Boris Zbarsky

unread,
May 31, 2016, 10:18:06 AM5/31/16
to blink-dev
On 5/30/16 9:15 AM, Philip Jägenstedt wrote:
> but are there worthwhile things that could be
> achieved if there was no blocking at all?

Absolutely. Consider this, in <body>:

<link rel="stylesheet" href="sheet1.css">
Various stuff not including <script>.
<link rel="stylesheet" href="sheet2.css">
More stuff

When do the loads of subresources sheet2 links to (e.g. @imports or
background images from it) start loading? If you block the parser on
sheet 1, they can't start loading until sheet1 is loaded without adding
some sort of special codepaths to prefetch those subresources. And
those specialy codepaths might not work correctly for background images
anyway, since those loads tend to only happen when some node matches the
rule...

If you don't block, things from sheet2 can load in the normal way.

In other words, blocking inherently gives up some parallelism. Parts of
it can probably be recovered with enough pain and suffering by UAs,
using various non-standardized heuristics and whatnot. But it adds
significant implementation complexity and more nonstandard things that
are needed in practice to create a useful UA...

-Boris

Elliott Sprehn

unread,
May 31, 2016, 3:39:06 PM5/31/16
to Boris Zbarsky, blink-dev
On Tue, May 31, 2016 at 7:17 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
On 5/30/16 9:15 AM, Philip Jägenstedt wrote:
but are there worthwhile things that could be
achieved if there was no blocking at all?

Absolutely.  Consider this, in <body>:

   <link rel="stylesheet" href="sheet1.css">
   Various stuff not including <script>.
   <link rel="stylesheet" href="sheet2.css">
   More stuff

When do the loads of subresources sheet2 links to (e.g. @imports or background images from it) start loading? 

@import is loaded by the preload scanner, background images are deferred until the first style recalc that would match that rule.
 
If you block the parser on sheet 1, they can't start loading until sheet1 is loaded without adding some sort of special codepaths to prefetch those subresources.

That already exists, it's the preload scanner, and I believe all browsers have it in some manner. The win from it was also so large I can't imagine anyone removing it. It seems reasonable to assume that browsers will implement a preload scanner (or some equivalent optimization), and that it's a part of the web:

 
And those specialy codepaths might not work correctly for background images anyway, since those loads tend to only happen when some node matches the rule...

Indeed, browsers only fetch resources declared in style rules on the first usage of them. This is what authors expect as well. Anything that started prefetching images from sheets without waiting on other pending sheets would likely start download images in rules that have overrides in other sheets.


If you don't block, things from sheet2 can load in the normal way.

In practice WebKit and Blink don't do that, they pretend content is display: none since the content after sheet1.css may depend on the styles in it, otherwise we FOUC. Edge blocks the parser here. I believe Gecko is the only engine that would FOUC that content today.


In other words, blocking inherently gives up some parallelism.

I don't think there's anything inherent about it, the preload scanner exists in all browsers, without it you'd load body resources too late and take a nasty perf hit for scripts or images in the body.
 
Parts of it can probably be recovered with enough pain and suffering by UAs, using various non-standardized heuristics and whatnot.  But it adds significant implementation complexity and more nonstandard things that are needed in practice to create a useful UA...

I don't think this is any worse than needing a preload scanner, which everyone has already. Especially given that both Blink and WebKit pretend the content is display: none, and IE and Edge block the parser, so most browsers are not fetching resources in the situations you describe. **

** This is not quite accurate, the behavior in WebKit/Blink is racy and buggy, so we do fetch sometimes, but it's hardly something authors can predict or understand. We've had years of complaints. The whole purpose of this project is to make the behavior not racy and instead make it predictable for authors. FOUC is frustrating, especially when you can't figure out why it works sometimes (ex. warm cache, network slowness, etc.).

- E 

Boris Zbarsky

unread,
May 31, 2016, 3:46:59 PM5/31/16
to Elliott Sprehn, blink-dev
On 5/31/16 3:38 PM, Elliott Sprehn wrote:
> @import is loaded by the preload scanner

Last I checked this is only the case for <style> in Blink, no? Not for
external stylesheets. Please do look at the actual example I suggested.

> background images are deferred
> until the first style recalc that would match that rule.

Precisely, and if you block the content that would match that rule from
being in the DOM, you don't get that style recalc until much later.

> If you block the parser on sheet 1, they can't start loading until
> sheet1 is loaded without adding some sort of special codepaths to
> prefetch those subresources.
>
> That already exists, it's the preload scanner, and I believe all
> browsers have it in some manner.

See above.

Note that Gecko's preload scanner does not parse inline stylesheets, by
the way. We can obviously fix that, but my larger point is that
blocking the parser requires a lot more than the sort of preload scanner
browsers typically already have, simply to get the parallelism you get
for free with not blocking the parser.

> Indeed, browsers only fetch resources declared in style rules on the
> first usage of them. This is what authors expect as well. Anything that
> started prefetching images from sheets without waiting on other pending
> sheets would likely start download images in rules that have overrides
> in other sheets.

That's actually not terribly likely to be a problem in practice, I expect.

> I don't think there's anything inherent about it

See above.

> I don't think this is any worse than needing a preload scanner, which
> everyone has already.

It's definitely worse, because it involves a lot more than just scanning
the HTML.

> so most browsers are not fetching resources in the situations you
> describe.

That's not true for @import in non-inline sheets.

-Boris

Elliott Sprehn

unread,
May 31, 2016, 4:21:17 PM5/31/16
to Boris Zbarsky, blink-dev
On Tue, May 31, 2016 at 12:46 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
On 5/31/16 3:38 PM, Elliott Sprehn wrote:
@import is loaded by the preload scanner

Last I checked this is only the case for <style> in Blink, no?  Not for external stylesheets.  Please do look at the actual example I suggested.

We have plans to expand support for @import.
 


background images are deferred
until the first style recalc that would match that rule.

Precisely, and if you block the content that would match that rule from being in the DOM, you don't get that style recalc until much later.

We don't today anyway, since we pretend the content is display: none.
 


    If you block the parser on sheet 1, they can't start loading until
    sheet1 is loaded without adding some sort of special codepaths to
    prefetch those subresources.

That already exists, it's the preload scanner, and I believe all
browsers have it in some manner.

See above.

Note that Gecko's preload scanner does not parse inline stylesheets, by the way.  We can obviously fix that, but my larger point is that blocking the parser requires a lot more than the sort of preload scanner browsers typically already have, simply to get the parallelism you get for free with not blocking the parser.

There's no free parallelism, we pretend the content is display: none.
 


Indeed, browsers only fetch resources declared in style rules on the
first usage of them. This is what authors expect as well. Anything that
started prefetching images from sheets without waiting on other pending
sheets would likely start download images in rules that have overrides
in other sheets.

That's actually not terribly likely to be a problem in practice, I expect.

We've had many complaints about this. Authors load base-theme.css, and then theme-overrides.css, if you don't have both of them loaded you'll download the images for base-theme incorrectly.
 

I don't think there's anything inherent about it

See above.

I don't think this is any worse than needing a preload scanner, which
everyone has already.

It's definitely worse, because it involves a lot more than just scanning the HTML.

We'll probably need that eventually anyway, for example scanning for @font-face can be a large win to avoid showing blank text while a font downloads.


so most browsers are not fetching resources in the situations you
describe.

That's not true for @import in non-inline sheets.

Indeed, I think we should try this and see how it works out though. Blocking the parser is very unlikely to break any content in WebKit/Blink/Edge or IE. Standardizing the Firefox behavior is full of risk though, it means any content which depended on the display: none or parser blocking of those four engines is going to FOUC.

Given that there's no agreement between engines, and that we've gone many years being inconsistent, I don't think we should worry about the standard just yet. We can experiment to see what behavior is the best.

- E 

Boris Zbarsky

unread,
May 31, 2016, 9:49:55 PM5/31/16
to blink-dev
On 5/31/16 4:20 PM, Elliott Sprehn wrote:
> There's no free parallelism, we pretend the content is display: none.

You're carefully ignoring the @import bit, yes?

Either that or we're seriously talking past each other.

> We've had many complaints about this. Authors load base-theme.css, and
> then theme-overrides.css, if you don't have both of them loaded you'll
> download the images for base-theme incorrectly.

Sure. But are authors doing that from inside <body>?

Also, note that we were talking about the following situation if I
understood correctly:

1) There are two stylesheets.
2) The earlier stylesheet overrides rules from the later one.
3) There is content between the two stylesheets that both sets of rules
apply to.

Or did I misunderstand?

> We'll probably need that eventually anyway, for example scanning for
> @font-face can be a large win to avoid showing blank text while a font
> downloads.

See my point in the spec issue: if we're going to lean so much on the
preload scanner, we need to spec it so UAs don't have to guess what
needs to be implemented to be web-compatible in practice.

> so most browsers are not fetching resources in the situations you
> describe.
>
> That's not true for @import in non-inline sheets.
>
>
> Indeed, I think we should try this and see how it works out though.

One thing I should note: Gecko _does_ in fact load @import inside
stylesheets loaded by the preload scanner. So that's not even an issue
for us. But it's not clear to me that this should be a hard requirement
for web browsers in general....

> Blocking the parser is very unlikely to break any content in
> WebKit/Blink/Edge or IE.

Sure. It'll just make it load slower or require a lot more complexity
to make it load just as fast. ;)

> Standardizing the Firefox behavior is full of
> risk though, it means any content which depended on the display: none or
> parser blocking of those four engines is going to FOUC.

That's true, if you hit all the things just wrong.

In practice, I believe we have gotten precisely zero but reports about this.

> We can experiment to see what behavior is the best.

Sure.

-Boris

Rick Byers

unread,
Jun 21, 2016, 1:50:03 PM6/21/16
to Boris Zbarsky, pme...@chromium.org, blink-dev
Patrick, so what do you want to do with this intent?  Do you want to move forward with this as planned?  I tend to agree with Elliot's point that it's probably OK to experiment with some changes here before we worry too much about locking down the spec.

Rick

Elliott Sprehn

unread,
Jun 21, 2016, 2:03:46 PM6/21/16
to Rick Byers, Boris Zbarsky, Patrick Meenan, blink-dev
On Tue, Jun 21, 2016 at 7:49 PM, Rick Byers <rby...@chromium.org> wrote:
Patrick, so what do you want to do with this intent?  Do you want to move forward with this as planned?  I tend to agree with Elliot's point that it's probably OK to experiment with some changes here before we worry too much about locking down the spec.



I met with bz about this to discuss the plan. In general browsers all disagree about what to do for stylesheets inserted in the head vs the body, <link> vs @import, and when to run requestAnimationFrame. I now understand his concern about @import, which Firefox doesn't block painting on, but given that other browsers do I think we're fine to change our behavior for now. We should also get numbers on how often pages force a layout with pending sheets since that would cause FOUC in Firefox, yet they don't hear lots of complaints. Perhaps there's something we're missing there. :) We should also look into getting a preload scanner spec so other browsers don't need to reverse engineer our optimizations. At this point all browsers have a scanner, so it seems a part of the web.

Here's my research:

Gecko:
    - block painting on sheets in head, anything that forces a style recalc results in FOUC.
    - Don't ever block painting on @import, even in <head>.
    - Give a FOUC answer to JS, and FOUC paint when triggered.
    - Start running requestAnimationFrame immediately even if we're not painting.

WebKit:
    - Block painting for both head and body, even for @import.
    - Give a FOUC answer to JS but don't paint. Buggy edge cases.
    - Start running requestAnimationFrame immediately even if we're not painting.

Edge:
    - Block painting for all sheets in <head>.
    - Block parser for all <link> sheets, don't block for @import.
    - Apply @import styles as they come in, non-atomic.
    - Start running requestAnimationFrame immediately even if we're not painting.
    - Give a FOUC answer to JS, but don't paint, but only for <head> sheets.

Blink:
    - Block painting for both head and body, even for @import.
    - Give a FOUC answer to JS but don't paint. Buggy edge cases.
    - Don't start running requestAnimationFrame until all sheets are loaded and we're in the <body>.

The long term plan here was to change Blink to:
- Block painting on all sheets in the head.
- Block the parser on sheets in the <body>.
- Don't start running requestAnimationFrame until we start painting.

This is more rational and simpler than what we have today where we pretend content is display: none, but return values to JS when forced, but still skip painting it even though we did compute the style, even bz commented that sounds "complicated' :P.

I think we should experiment with this simpler model and see what impact is has on existing content, and the programming model. For async sheets I think we should instead consider adding an async keyword to <style> and <link> so it's not just @import getting the optimization, and not just in one browser.

- E 

Boris Zbarsky

unread,
Jun 21, 2016, 2:35:54 PM6/21/16
to Elliott Sprehn, Rick Byers, Patrick Meenan, blink-dev
On 6/21/16 2:03 PM, Elliott Sprehn wrote:
> Gecko:
> - block painting on sheets in head, anything that forces a style
> recalc results in FOUC.
> - Don't ever block painting on @import, even in <head>.

You mean @import in inline sheet or in external sheet?

We should be blocking painting on @import in external sheet (basically
because we don't consider the external sheet loaded until all its
imports re loaded). We may not be doing so on @import in inline sheet.

-Boris

Elliott Sprehn

unread,
Jun 21, 2016, 2:57:42 PM6/21/16
to Boris Zbarsky, blink-dev, Patrick Meenan, Rick Byers

Yeah on an internal sheet. I can run the tests again checking external sheets too. I'll get my test setup up on github so folks can try it as well.

- E

Rick Byers

unread,
Jun 21, 2016, 4:26:13 PM6/21/16
to Elliott Sprehn, Boris Zbarsky, blink-dev, Patrick Meenan
Thanks for all the research / discussion Elliott!  Sounds like a reasonable next step to me.  We'll learn more by trying this and can then circle back on how best to converge on interop.  LGTM1.

Philip Jägenstedt

unread,
Jun 22, 2016, 11:41:21 AM6/22/16
to Rick Byers, Elliott Sprehn, Boris Zbarsky, blink-dev, Patrick Meenan
LGTM2. The suggested behavior sounds like it'll be easier to reason about, but it's quite hard to judge the risk here. Hope it works out :)

Jochen Eisinger

unread,
Jun 22, 2016, 11:54:34 AM6/22/16
to Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky, blink-dev, Patrick Meenan

lgtm3

Patrick Meenan

unread,
Jun 24, 2016, 11:54:05 AM6/24/16
to Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky, blink-dev, Patrick Meenan
Sorry about the delay, just getting back from Velocity.  Just a quick check on the LGTM's, those are for the plan Elliott outlined, correct?

The long term plan here was to change Blink to:
- Block painting on all sheets in the head.
- Block the parser on sheets in the <body>.
- Don't start running requestAnimationFrame until we start painting.

If so then I'll go ahead and proceed with blocking the parser for the in-body external styles.  As far as specs go, I can add a note to the issue that we're proceeding with implementing the Edge behavior and kick off some discussions about adding an async attribute for the Firefox behavior.

Chris Harrelson

unread,
Jun 24, 2016, 12:11:28 PM6/24/16
to Patrick Meenan, Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky, blink-dev
Hi Patrick,

I'm a little unsure what the exact new plan is, in terms of differences from today's behavior and updated summary of compatibility. Could you summarize it more explicitly? Are you proposing to directly implement the long-term plan?

Thanks,
Chris

Patrick Meenan

unread,
Jun 24, 2016, 12:24:49 PM6/24/16
to Chris Harrelson, Patrick Meenan, Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky, blink-dev
Yes, I can directly implement the long-term plan. The current code behind a flag was necessary to be able to continue painting if we block the parser in the body.  Adding the parser blocking will take care of the first 2 bullets. 

I don't know the current state of RAF but I can tackle any change needed there as well. 

Chris Harrelson

unread,
Jun 27, 2016, 1:38:40 PM6/27/16
to Patrick Meenan, Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky, blink-dev
Ok. LGTM from me to implement and experiment, but I'm concerned about a lack of spec w/ consensus among vendors for what compat behavior should be, before shipping. The behavior of the loading sequence is very important to spell out, and as evidenced by this thread, has quite a bit of subtlety and potentially unexpected behavior.

Chris

Patrick Meenan

unread,
Mar 9, 2017, 10:14:21 AM3/9/17
to Chris Harrelson, Patrick Meenan, Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky, blink-dev
Following up on this intent now that the implementation has evolved.  As of the end of January (2017) our experimental implementation has matched the Edge behavior where in-body external stylesheets block the parser (and render) for content after the link tag but content before it is free to continue rendering.  As of this morning WebKit implements similar behavior and only blocks render for elements defined after the body stylesheets.

Our implementation has been behind the experimental web platform features flag and has been the default on the bots for the past 6 months.

What would be the best next steps? Some options that come to mind:
- Enable on Canary
- Run a finch trial to see impact on First Meaningful Paint or other metrics

If a reasonable number of sites are impacted I'd expect FMP to improve but realistically I don't expect a lot of existing sites to benefit.  Most that use the lazy-loading CSS techniques for performance already have the necessary hoops in place to use loadCSS or a similar library to load it asynchronously.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.



akoi...@gmail.com

unread,
Mar 9, 2017, 11:38:33 AM3/9/17
to blink-dev, chri...@chromium.org, pme...@chromium.org, joc...@chromium.org, foo...@chromium.org, rby...@chromium.org, esp...@chromium.org, bzba...@mit.edu


On Thursday, March 9, 2017 at 5:14:21 PM UTC+2, Patrick Meenan wrote:
Following up on this intent now that the implementation has evolved.  As of the end of January (2017) our experimental implementation has matched the Edge behavior where in-body external stylesheets block the parser (and render) for content after the link tag but content before it is free to continue rendering.  As of this morning WebKit implements similar behavior and only blocks render for elements defined after the body stylesheets.

Right. WebKit implementation does not block the parser. Instead it blocks style resolution and renderer construction after the first pending body stylesheet. In case a layout query forces full renderer construction we block painting for such renderers (to avoid FOUC). This is essentially just a tweak to our existing model of handling pending stylesheets. 

I think parser blocking may be unnecessarily big of a hammer to get the desired behavior.


  antti

Patrick Meenan

unread,
Mar 9, 2017, 12:03:52 PM3/9/17
to akoi...@gmail.com, blink-dev, Chris Harrelson, pme...@chromium.org, Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky
I don't know the webkit patch well enough to know the side-effects but the biggest benefit for blocking the parser is that layout, styles, etc can continue to change for the parts of the page that existed before the external stylesheet was referenced (say, as images and fonts load).  We also no longer need to worry about blocking anything to avoid FOUC because the unstyled elements don't exist on the DOM yet.

Patrick Meenan

unread,
Mar 27, 2017, 9:31:48 AM3/27/17
to akoi...@gmail.com, blink-dev, Chris Harrelson, pme...@chromium.org, Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky
Sorry for the delay, finally dug out my Mac so I could test the WebKit implementation and it fails in the ways I expected.

I have a few test pages linked from here.  The ones of particular interest are "External CSS at middle of Body" and "External CSS at end of Body".  In both cases there is a document that looks roughly like this:

<head></head>
<body>
<image that takes 1 second to load (server-side delay)>
<image that loads immediately>

There is a CSS file (either between the two images or after the last image) that takes 5 seconds to load that changes the body background to black so you can tell when it has loaded.  In both cases you would expect to see the first image load and render while the CSS is loading and then change the body background to black.  In the "middle" case you expect the second image to only render after the CSS has loaded but in the "end" case you expect to see it render immediately (before the first image).

In both cases WebKit doesn't render the 1-second delayed image until after the css has loaded.

Blocking the parser is also not that heavy of a hammer in this case because the parser would have to stop anyway at the next script tag it encountered and wait for the CSS to finish loading anyway.  It also makes the underlying layout/paint states a lot easier to reason about (never going back into a blocking state) and makes it much easier for developers/users to reason about.

All that said, it looks like something has broken in the latest canaries and the rendering isn't unblocking like it is supposed to (stable has the pre-blocking part that behaves like the Mozilla implementation).  I'll need to track down what else changed that broke the experimental path.



On Thu, Mar 9, 2017 at 11:38 AM, koiv...@iki.fi <akoi...@gmail.com> wrote:

Rick Byers

unread,
Mar 27, 2017, 12:05:43 PM3/27/17
to Patrick Meenan, Chris Harrelson, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky
Thanks for continuing to push on this Patrick!
I think you want to work with Chris or someone else on the paint team to formulate the plan for shipping a change here.  Ideally we'd be proposing some spec improvements / interop tests to try to nudge the engines on a path to convergence here.  But I defer to Chris on what the bar should be for shipping any specific change along the path - we don't want perfect to be the enemy of "better".

Rick

Rick Byers

unread,
Mar 27, 2017, 2:26:02 PM3/27/17
to Patrick Meenan, Chris Harrelson, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky, Eddy Mead
To be clear, my LGTM from June still stands.  Moving closer to Edge seems low enough risk that I don't personally see any reason why we'd need to block shipping on improving the spec situation here (though we definitely need to be on the look-out for reports of issues in the wild and be ready to re-evaluate).  But Chris had some concerns with that plan back in June.  Chris, what's your current thinking on what specifically you'd like to see before we try shipping a change here?

Also note I was wrong about this being a paint-team thing (sorry - forgot the history and skimmed the thread too quickly).  I do still want to know what team owns this space long term.  I.e. who owns the decision of what spec / interop work, if any, will be prioritized over the next year or so after we've realized the performance win? 

 

Antti Koivisto

unread,
Mar 27, 2017, 7:30:40 PM3/27/17
to Patrick Meenan, blink-dev, Chris Harrelson, Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky
Which version of WebKit did you use? I tried these tests and they seem to work as expected (images appear at right times) in the latest Safari Technology Preview (26). The behaviour has not yet shipped outside STP.

Note that the patch was out of the WebKit tree for the last few days due to some performance issues (https://webkit.org/b/149157 for details) but it is now back in.


  antti

Patrick Meenan

unread,
Mar 28, 2017, 7:52:32 AM3/28/17
to Antti Koivisto, Patrick Meenan, blink-dev, Chris Harrelson, Jochen Eisinger, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Boris Zbarsky
Ah, thanks - I was using the latest WebKit nightly at the time so probably caught the window at a bad time.  I'll take a closer look at the patch itself to see how it translates to blink and if any side-effects jump out.  One of the things we were looking forward to doing was simplifying the render state logic so hopefully it doesn't add more complexity to that.  I'm glad to hear the user/developer-facing behavior is effectively the same - that will make the best practices message a lot cleaner when it has rolled out.

Chris Harrelson

unread,
Mar 28, 2017, 9:44:49 PM3/28/17
to Rick Byers, Patrick Meenan, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky, Eddy Mead
On Mon, Mar 27, 2017 at 11:25 AM, Rick Byers <rby...@chromium.org> wrote:
To be clear, my LGTM from June still stands.  Moving closer to Edge seems low enough risk that I don't personally see any reason why we'd need to block shipping on improving the spec situation here (though we definitely need to be on the look-out for reports of issues in the wild and be ready to re-evaluate).  But Chris had some concerns with that plan back in June.  Chris, what's your current thinking on what specifically you'd like to see before we try shipping a change here?

I think my original concern still stands. I don't think we should ship new behavior without a spec story. I think we need at least a strong vision doc explaining why this change will result in good performance and ergonomics, and that other vendors & experienced developers (Facebook? Others?) agree that it scales to complicated sites in the best way. Fast/scalable loading is very important to the web, and so is predictability of what will happen during that loading. 

To further clarify my position, I see no reason why the proposal in this intent is the wrong path. It sounds good to me, and does sound like it reduces compat issues between browsers. But I think this space is important enough to get it right the first time (maybe run an intent to experiment?). I also think that no matter what, changing these semantics will break some content, probably more than usual. It's worth it to fix the loading story, but again we should do it right and not break things twice.


Also note I was wrong about this being a paint-team thing (sorry - forgot the history and skimmed the thread too quickly).  I do still want to know what team owns this space long term.  I.e. who owns the decision of what spec / interop work, if any, will be prioritized over the next year or so after we've realized the performance win? 

I am not sure of the current status either.

Thanks all,
Chris

Eddy Mead

unread,
Mar 28, 2017, 11:59:38 PM3/28/17
to Chris Harrelson, Rick Byers, Patrick Meenan, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky, Shane Stephens, domi...@chromium.org
Hmm, I guess the style team owns it, especially if you consider esprehn and rune as people who have the context who are part of my team. Although, if I look at the code in the linked CL, it's mostly in core/dom?

Patrick Meenan

unread,
Mar 29, 2017, 11:48:18 AM3/29/17
to Eddy Mead, Chris Harrelson, Rick Byers, Patrick Meenan, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky, Shane Stephens, domi...@chromium.org
The style side of things (to not block painting) was done in a different CL ~10 months ago.  As far as breaking content, it should only change something that might have been racy before into something deterministic (i.e. if the HTML stream got chunked such that there was a delay before any in-body style tokens were received).

As far as the spec side of things go, is there a particular w3c group I should try to work with?  Render/paint doesn't have a good home and it falls somewhere between the CSS and HTML specs (parser and layout behaviors).

Dimitri Glazkov

unread,
Mar 29, 2017, 6:56:18 PM3/29/17
to Patrick Meenan, Eddy Mead, Chris Harrelson, Rick Byers, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky, Shane Stephens, domi...@chromium.org
What would be the scope of work for writing such a spec? I share Chris' concern for better interoperability, but I am also worried that we might be looking at a multi-year effort -- as I understand it, this is not something that's well-specified or even has agreement across browser vendors.

:DG<

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.









Patrick Meenan

unread,
Mar 30, 2017, 11:09:58 AM3/30/17
to Dimitri Glazkov, Patrick Meenan, Eddy Mead, Chris Harrelson, Rick Byers, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky, Shane Stephens, Dominic Cooney
To get all of the browsers fully aligned would span at least a few different specs and probably some areas that aren't spec'd.  It covers the intersection of the parser, building the DOM and building a render tree.

Specifically, when a stylesheet is parsed in the body of a document (either link or style tags) and before it has been loaded and processed:
- Should DOM elements discovered after the stylesheet be added to the DOM? (IE/Edge: No, Firefox and Safari: Yes, Chrome CL: No)
- Should elements discovered after the stylesheet be added to a render tree (causing FOUC)? (IE/Edge/Chrome CL: N/A, Firefox: Yes , Safari: No)
- Should Layout/Render/Paint continue for elements discovered before the stylesheet? (Everyone: Yes - Shipping Chrome/Safari: No)

In general, anything about when to paint (or allow paint) isn't spec'd and is mostly tuned by everyone to minimize re-doing work as much as possible, reduce FOUC and still display content to the user as soon as possible but pretty much nothing about when rendering is or isn't supposed to happen lies in any specs (that I'm aware of anyway).


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.










Chris Harrelson

unread,
Mar 30, 2017, 12:03:08 PM3/30/17
to Patrick Meenan, Dimitri Glazkov, Eddy Mead, Rick Byers, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky, Shane Stephens, Dominic Cooney
On Thu, Mar 30, 2017 at 8:09 AM, Patrick Meenan <pme...@chromium.org> wrote:
To get all of the browsers fully aligned would span at least a few different specs and probably some areas that aren't spec'd.  It covers the intersection of the parser, building the DOM and building a render tree.

Specifically, when a stylesheet is parsed in the body of a document (either link or style tags) and before it has been loaded and processed:
- Should DOM elements discovered after the stylesheet be added to the DOM? (IE/Edge: No, Firefox and Safari: Yes, Chrome CL: No)
- Should elements discovered after the stylesheet be added to a render tree (causing FOUC)? (IE/Edge/Chrome CL: N/A, Firefox: Yes , Safari: No)
- Should Layout/Render/Paint continue for elements discovered before the stylesheet? (Everyone: Yes - Shipping Chrome/Safari: No)

In general, anything about when to paint (or allow paint) isn't spec'd and is mostly tuned by everyone to minimize re-doing work as much as possible, reduce FOUC and still display content to the user as soon as possible but pretty much nothing about when rendering is or isn't supposed to happen lies in any specs (that I'm aware of anyway).

Hi Patrick, 

I agree with you that to date it seems browsers have applied what heuristics they can to optimize things during loading, while retaining "enough" compatibility. There also seem to be gray areas even post-load having to do with what happens when new DOM elements are added or changed that depend on external async-loadable resources like CSS, images, etc.

I'm not asking for all browsers to be fully aligned and it to be written down in all the relevent specs, before your change ships. Many intents ship without achieving that, and your case is harder than most because it seems there is a lack of specs to edit. Sorry about that. :(

But I do think we should start an effort, talk with web community stakeholders about the issues involved, get their feedback, figure out what is spec'ed and where we might put the specs over time, have a draft spec-like document that spells out the answers to all the yes/no questions you mentioned above, and get browsers to say whether they would be ok moving towards that spec over time, or if not why not.

Thanks-
Chris

Anne van Kesteren

unread,
Mar 31, 2017, 1:26:46 AM3/31/17
to Patrick Meenan, Dimitri Glazkov, Eddy Mead, Chris Harrelson, Rick Byers, akoi...@gmail.com, blink-dev, Jochen Eisinger, Philip Jägenstedt, Elliott Sprehn, Boris Zbarsky, Shane Stephens, Dominic Cooney
On Thu, Mar 30, 2017 at 5:09 PM, Patrick Meenan <pme...@chromium.org> wrote:
> To get all of the browsers fully aligned would span at least a few different
> specs and probably some areas that aren't spec'd. It covers the
> intersection of the parser, building the DOM and building a render tree.
>
> Specifically, when a stylesheet is parsed in the body of a document (either
> link or style tags) and before it has been loaded and processed:
> - Should DOM elements discovered after the stylesheet be added to the DOM?
> (IE/Edge: No, Firefox and Safari: Yes, Chrome CL: No)
> - Should elements discovered after the stylesheet be added to a render tree
> (causing FOUC)? (IE/Edge/Chrome CL: N/A, Firefox: Yes , Safari: No)
> - Should Layout/Render/Paint continue for elements discovered before the
> stylesheet? (Everyone: Yes - Shipping Chrome/Safari: No)
>
> In general, anything about when to paint (or allow paint) isn't spec'd and
> is mostly tuned by everyone to minimize re-doing work as much as possible,
> reduce FOUC and still display content to the user as soon as possible but
> pretty much nothing about when rendering is or isn't supposed to happen lies
> in any specs (that I'm aware of anyway).

I don't think that's actually true. HTML defines when rendering can
happen and it has to do so to make sure all kinds of events end up
being dispatched before that happens. HTML also defines the HTML
parser, <link rel=stylesheet>, and some amount of blocking related to
<script> elements. It could conceivably define this as well.

In particular you'd have to modify step 7 of
https://html.spec.whatwg.org/#event-loop-processing-model somehow. And
if you also want to block the DOM being created you could modify the
HTML parser for that. It would be some work, but it doesn't seem
enormously difficult on the face of it.


--
https://annevankesteren.nl/

Philip Jägenstedt

unread,
Apr 7, 2017, 12:01:09 PM4/7/17
to Anne van Kesteren, Patrick Meenan, Dimitri Glazkov, Eddy Mead, Chris Harrelson, Rick Byers, akoi...@gmail.com, blink-dev, Jochen Eisinger, Elliott Sprehn, Boris Zbarsky, Shane Stephens, Dominic Cooney
Patrick, how do you view the prospects of standardization here? All of this web exposed at least in the sense that web developers need to adapt to it, and I presume at least some of it would be possible to test using web-platform-tests.

https://wiki.whatwg.org/wiki/Specs/todo is not really maintained, but if you would explain in a sentence what it is that's missing here spec-wise, what is it?

Jake Archibald

unread,
Apr 15, 2017, 6:10:09 AM4/15/17
to Philip Jägenstedt, Anne van Kesteren, Patrick Meenan, Dimitri Glazkov, Eddy Mead, Chris Harrelson, Rick Byers, akoi...@gmail.com, blink-dev, Jochen Eisinger, Elliott Sprehn, Boris Zbarsky, Shane Stephens, Dominic Cooney
If we're wanting to go down the Safari TP model, we could do it like this:

A stylesheet is loading until it's stylesheet resource, and any inner @imported sheets load.

The parser has a list of parser-inserted stylesheets.

When a <link rel="stylesheet"> or <style> is discovered, it's added to the list of parser-inserted stylesheets.

Every node has a list of render-blocking stylesheets. When a node is created, its render-blocking stylesheets is a copy of the parser's parser-inserted stylesheets.

A node won't render while there are loading stylesheets in its render-blocking stylesheets.

This allows for the potentially weird behaviour:

<script>
setTimeout(() => {
  document.querySelector('p').after('Foo!')
}, 1000);
</script>
<link rel="stylesheet" href="slow-stylesheet.css">
<p>Hello</p>
<p>World</p>

…where text node "Foo" may render while the paragraph before it "Hello" is render-blocked. This doesn't feel like a big deal though - if you want parser-blocking behaviour, move the <script> after the <link>.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Elliott Sprehn

unread,
Apr 17, 2017, 11:41:39 PM4/17/17
to Jake Archibald, Philip Jägenstedt, Anne van Kesteren, Patrick Meenan, Dimitri Glazkov, Eddy Mead, Chris Harrelson, Rick Byers, akoi...@gmail.com, blink-dev, Jochen Eisinger, Boris Zbarsky, Shane Stephens, Dominic Cooney
On Sat, Apr 15, 2017 at 3:09 AM, Jake Archibald <jakear...@google.com> wrote:
If we're wanting to go down the Safari TP model, we could do it like this:

I don't think we should go with the Safari TP behavior for a number of reasons which is why our discussion has been around either the Firefox behavior (making sheets async), or the Edge behavior (block the parser). It was decided that blocking the parser had really nice developer ergonomics which is why we landed there.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Antti Koivisto

unread,
Apr 18, 2017, 10:21:23 AM4/18/17
to Jake Archibald, Philip Jägenstedt, Anne van Kesteren, Patrick Meenan, Dimitri Glazkov, Eddy Mead, Chris Harrelson, Rick Byers, blink-dev, Jochen Eisinger, Elliott Sprehn, Boris Zbarsky, Shane Stephens, Dominic Cooney
The current STP behaviour is 

- When resolving style, elements are styled normally until first element with loading stylesheet (in tree order) is encountered. 
- In case of a normal style resolution styles for further unstyled elements are not computed (and so no new renderers are constructed). 
- In case a script queries layout-dependent properties while there are still pending stylesheets (good old updateLayoutIgnorePendingStylesheets) we resolve style for all elements. Any new styles for elements after loading stylesheets are marked with 'non-final' bit. 
- Renderers with 'non-final' bit set are not painted to avoid FOUC.
- Completing stylesheet load will trigger style resolution that clears 'non-final' styles as needed.

If all stylesheets are in head then this reduces to the current WebKit (and I think Blink too) behavior.

Does the suggested parser blocking behavior mean you would block parser for head stylesheets too? 


    antti

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Patrick Meenan

unread,
Apr 18, 2017, 2:36:03 PM4/18/17
to Antti Koivisto, Jake Archibald, Philip Jägenstedt, Anne van Kesteren, Patrick Meenan, Dimitri Glazkov, Eddy Mead, Chris Harrelson, Rick Byers, blink-dev, Jochen Eisinger, Elliott Sprehn, Boris Zbarsky, Shane Stephens, Dominic Cooney
No, the parser blocking is only for external sheets referenced from the body.  When a new stylesheet is added, it checks to see if the current document has a body yet.  Stylesheets imported from other stylesheets inherit their parent's body position.  Stylesheets loaded before a body exists are considered "render blocking" and the existing logic is carried forward until all render-blocking stylesheets have loaded.  Any non-render-blocking stylesheet loads will pause the parser until they have finished loading.