[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]