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

Awesome, thanks Chris.

On Mon, Jan 15, 2018 at 11:56 AM, Chris Harrelson <chrishtr@chromium.org>
wrote:

>
>
> On Mon, Jan 15, 2018 at 8:37 AM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>> +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?
>>
>
> Let's use https://github.com/whatwg/html/issues/3355. I linked from there
> to other issues and related past Chromium efforts.
>
>
>>
>> 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/
>>>>
>>>>
>>>
>>
>