On Thu, Oct 30, 2014 at 2:44 PM, Ben Maurer <ben.mau...@gmail.com> wrote: > > On Thu, Oct 30, 2014 at 2:26 PM, Ilya Grigorik <igrigo...@gmail.com> > wrote: >> >> On Thu, Oct 30, 2014 at 12:17 PM, Ben Maurer <ben.mau...@gmail.com> >> wrote: >> >>> We talked a bit before about the idea of async stylesheets (like async >>> scripts). That kind of functionality could implement something similar to >>> this proposal (though in a bit more of a clunky way -- you need to have an >>> inline visibility:hidden style for the content you want to hide then >>> override that in css). >>> >> >> Right, the problem with previous proposals for async stylesheets is that >> it is really hard to reason about how+when they will be applied, which >> would force you to manually hide most of the content and then modify the >> visibility when stylesheet is ready... at least, if you want to avoid FOUC. >> The proposal here is an in-between solution that's much simpler to deploy: >> the position of the <link> in the doc acts as a hint that DOM-content >> before it does not have to block paints on it, so the UA can do the >> bookkeeping for what can be painted vs what should remain hidden. All the >> developer has to do is move the <link>'s in right positions in the doc. >> > > To be clear -- I'm suggesting we do both, not just async scripts. I agree > that async stylesheets are harder to use. However, they also make some use > cases simpler (For example, Facebook implements the idea of an "early > flush" -- when we get a request we render all the resources we think the > page might need before doing any computation. async stylesheets would > prevent these resources from blocking early parts of the page). >
Speaking of a generic solution, I think rel=preload does would address, right? e.g. <link rel=preload as=stylesheet href=...> - that would initiate an early fetch and not cause any blocking behaviors, since preload is simply a declarative fetch that works for any content type. > It seems like there's a consistency problem between script loading and >>> stylesheet loading. Would it be worth trying to ensure there is parity >>> between those two things. Script tags already implement the behavior you >>> are suggesting (a <script> can be inside the document body and will only >>> block content that occurs after it). >>> >> >> Depends on what you mean by parity? If you mean async, etc, then >> personally I'd prefer that we keep that as a separate discussion (and I'm >> not convinced we need async for stylesheets). What we're proposing here >> requires minimal change to the spec and reflects the (already) implemented >> patterns both in markup and in some rendering engines... a simple update >> that could pay high perf dividends. >> > > So by parity I mean we should try to make sure roughly the same set of > tools are available for loading scripts and stylesheets. For example, today > you can achieve the semantic of "this resource should only block resources > after it" with scripts: > > <body> > <div>Fast content</div> > <script src=... /> > <div>This will only show up after the script is loaded</div> > </body> > > This proposal would add that functionality for stylesheets. I think this > is a good thing. > Great, we're on the same page then. > But I think it will be simpler for web developers if we can have similar > functionality for script and stylesheet loading. This way we don't have to > explain "if you want a script not to block the page, we recommend you use > async. On the other hand, if you have a stylesheet, you have to put it in > the middle of the body". Having both things lets us have a simple > explanation: "Your CSS/JS will block content that comes after it in the DOM > unless you use the async tag. Use the async tag if you can tolerate the > resource in question not being loaded". > (when you have hammer everything looks like a... :-)) I think we can implement these via rel=preload? Initiate the fetch, wait for load event on the fetch to fire, and inject into the doc - aka, "async" for any content type. ig
