- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Sun, 14 Jan 2018 08:50:10 +0100
- 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