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