Re: Using preload for "async" CSS by changing `rel` trick

On Sat, Jan 13, 2018 at 7:23 PM, Ilya Grigorik <> wrote:
> Anne, what's missing for preload specifically? Happy to address it if we
> can.

> My observation here is that you can remove preload out of this question and
> rephrase it as: "If I programmatically inject a <link rel=stylesheet> what
> execution guarantees, if any, are provided?"

I think it's more complex. It's a combination of:

* What does the standard say
* What do implementations do
* What do websites rely on

where the latter two are much more important than the first. I think
ideally it's always asynchronous, but in practice <script> can block
on the stylesheet being loaded (this is defined in HTML). Ben's
example shows something different however which relates to the
"implementation details" (not quite as they're observable) of preload
in Chromium and WebKit. That also shows why it's important to define
this. If sites start to rely on <link rel=preload onload> and from
that event handler inject a <link rel=stylesheet> of which they then
immediately query the styles, it better be defined as otherwise
browsers are back at having to reverse engineer each other to figure
out how the web works.

(I'm sure you've seen the "X is the new IE6" meme. This is really what
that comes down to.)


Received on Sunday, 14 January 2018 07:50:36 UTC