Re: [whatwg] allow <link> in body + DOM position as a rendering hint

On Thu, Oct 30, 2014 at 2:44 PM, Ben Maurer <ben.maurer@gmail.com> wrote:
>
> On Thu, Oct 30, 2014 at 2:26 PM, Ilya Grigorik <igrigorik@gmail.com>
> wrote:
>>
>> On Thu, Oct 30, 2014 at 12:17 PM, Ben Maurer <ben.maurer@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

Received on Thursday, 30 October 2014 22:14:09 UTC