[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] Lazy loading
From:       Maciej Stachowiak <mjs () apple ! com>
Date:       2019-10-28 23:36:48
Message-ID: FC4DE084-DA20-4E61-8309-ACD4F80E9D6C () apple ! com
[Download RAW message or body]



> On Oct 28, 2019, at 3:08 PM, Rob Buis <rbuis@igalia.com> wrote:
> 
> On 10/28/19 9:07 PM, Maciej Stachowiak wrote:
> 
> > > Yet another possible task is making lazy loading work for CSS backgrounds, this is implemented in \
> > > the prototype but I don't think there are many tests for it.
> > Is there a way for content authors to opt in/out (depending on the default), or does this just always \
> > follow what the default lazy loading setting is?
> 
> From reading the chromium code, it seems to use a combination of feature policy and the loading \
> attribute to decide whether to enable CSS backgrounds lazy loading or not. Hopefully a chromium \
> developer can confirm.

Per the PR for lazy loading[1], the `loading` attribute applies only to `<img>` and `<iframe>` elements. \
Most CSS background images are not on either of these specific elements. I can imagine one of the \
following:

- Chromium has a nonstandard extension beyond what is in the PR to make `loading` a global/superglobal \
                attribute (in which case we probably shouldn't implement that until spec'd)
- The attribute only applies to CSS backgrounds on specifically the `<img>` and `<iframe>` elements, \
                which would be weirdly limited, and also would be a nonstandard extension to the PR
- CSS backgrounds (and other CSS images?) don't have an individual override, only the global override via \
Feature Policy.

This raises two further concerns though:
- Lazy loading for CSS images is not specified in the lazy loading PR[1]. Is it specified elsewhere, or \
                is it a nonstandard Chromium extension?
- I couldn't find a spec for a lazy loading feature policy either, and the Chrome Platform Status page \
for it gives the status as "removed"[2] so this too might be a nonstandard thing. Or maybe there is a \
newer  (Doesn't look like the feature policy aspect is in your patch though.)

I hope I am not being too nitpicky. I do think this is a great feature. I just want to make sure we're \
cautious about the line between implementing standards-track stuff vs copying things from Chromium that \
are nonstandard or unspecified (so far).

It's also really worrisome if Chrome implemented semantics for the "loading" attribute beyond what is in \
the PR, as that will make interop a challenge.

Regards,
Maciej

[1] <https://github.com/whatwg/html/pull/3752>
[2] <https://www.chromestatus.com/feature/5641405942726656>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[prev in list] [next in list] [prev in thread] [next in thread]