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

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).

>
>
>> 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. 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".

Received on Thursday, 30 October 2014 21:45:04 UTC