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

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