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

+yoav

Thanks all for feedback!

On Sun, Jan 14, 2018 at 12:05 PM, Chris Harrelson <chrishtr@chromium.org>
wrote:

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

That's a good example that would be nice to drive clarity on. On a related
note, I think we also need to explore what happens under memory pressure to
various renderer/memory caches in our pipelines. In the case of preload,
the renderer may also be holding on to a non-cacheable HTTP response, in
which case it'd be nice for us to have some smarts for how things are
evicted.

Let's continue this part of the thread in:
https://github.com/whatwg/fetch/issues/590


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

Where's the right place to surface and keep track of this conversation? CSS
WG, somewhere else?

ig


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