W3C home > Mailing lists > Public > public-web-perf@w3.org > January 2018

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Sun, 14 Jan 2018 08:50:10 +0100
Message-ID: <CADnb78hW-TS-OKXt62VEwKg9B6sPexuoDaKzb4TeD_i7p-xtoA@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>
Cc: Ben Maurer <ben.maurer@gmail.com>, Philip Walton <philipwalton@google.com>, Royi Hagigi <royi@fb.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Sat, Jan 13, 2018 at 7:23 PM, Ilya Grigorik <igrigorik@google.com> wrote:
> Anne, what's missing for preload specifically? Happy to address it if we
> can.

https://github.com/w3c/preload/issues/97.


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


-- 
https://annevankesteren.nl/
Received on Sunday, 14 January 2018 07:50:36 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 14 January 2018 07:50:37 UTC