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

I share Ben's concern that the relationship between the browser cache and
rendering behavior during the lifetime of a web page is insufficiently
specified to be fully reliable. I also agree with Ilya that the issue is
orthogonal to preload. I'd call it a rendering pipeline definitional issue
rather than a resource loading issue.

Two examples for images, in which onload does not guarantee that the next
frame will show an image. Reasons: (1) image decoding may be async, and (2)
image caching may be async.

Progress has been made very recently on (1), by defining the async
attribute on images. Chrome now respects them. However, there are still
situations where (2) is a problem. e.g. I believe that if an <img> were
removed from the DOM and re-inserted, it may not be in the memory cache
(instead would be in the on-disk cache, or not even there), meaning that it
would not necessarily display in the next frame. It's also a problem when
reloading a "cached" web app - the images may not appear in time to avoid
flashing.

Regarding style sheets: I think the spec / implementations should ensure
that "loaded" style sheets always apply to the next frame drawn to the
screen. I'm hoping we can make progress addressing cases in which this
fails in 2018. Blink and Webkit both have some strange and heuristic
behavior during load regarding how style sheets apply, which we should try
to fix.

Chris

On Sat, Jan 13, 2018 at 11:50 PM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> 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/
>
>