Re: [webkit-dev] Lazy loading

[Rob Buis]

Regarding lazily loading CSS background images, Chromium determines whether
or not to lazily load CSS background images according to the default lazy
loading behavior, and isn't directly controlled by the "loading" attribute.
There are some heuristics involved, e.g. background images inside an iframe
that was itself lazily loaded are loaded eagerly for performance reasons,
but those heuristics are just part of the default lazy loading behavior.


Scott, thanks for the clarification! Are there plans to better specify 
CSS background images lazy loading?


Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Rob Buis]

Apologies, it seems I spread some misinformation about CSS background 
lazy loading, which Scott rectified.


On 10/29/19 12:36 AM, Maciej Stachowiak wrote:




On Oct 28, 2019, at 3:08 PM, Rob Buis  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.

- 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.)
The prototype was done in February. I think Youenn was starting 
implementation of feature policy at the same time or maybe later. Then 
later I did not really touch CSS background lazy loading again, since 
there were a lot of other issues instead to address, one of them being 
the spec was changing over time. Will be happy with addressing it now, 
though I am not sure how impactful it will be for users compared to lazy 
image loading.

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).


Understood.

Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Scott Little]

Regarding lazily loading CSS background images, Chromium determines whether
or not to lazily load CSS background images according to the default lazy
loading behavior, and isn't directly controlled by the "loading" attribute.
There are some heuristics involved, e.g. background images inside an iframe
that was itself lazily loaded are loaded eagerly for performance reasons,
but those heuristics are just part of the default lazy loading behavior.

Cheers,
- Scott
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Maciej Stachowiak]

> On Oct 28, 2019, at 3:08 PM, Rob Buis  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 `` 
and `` 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 `` and 
`` 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] 
[2] 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Rob Buis]

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.


Regards,

Rob.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Maciej Stachowiak]

> On Oct 28, 2019, at 11:39 AM, Rob Buis  wrote:
> 
> Hi,
> 
> I made a lazy image loading prototype earlier this year 
> (https://bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting it 
> up into reviewable patches. The main implementation part landed recently so I 
> am wondering about the next steps.
> 
> One thing left to do for sure is cleaning up/adding tests. For one there are 
> tests in http/tests/lazyload which can just be WPT tests, so I'll work in 
> this area for sure. As usual, while adding new tests bugs may show up and 
> more patches will be needed.
> 
> Another possible task is implementing metadata fetch, but it makes the code 
> more complex and chromium has backtracked from it.
> 
> Changing the behavior of loading=auto to make lazy loading the default seems 
> risky and should possibly only be done when lazy image loading is deemed 
> stable enough.
> 
> 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?

> 
> A related task is implementing lazy loading for iframe's, I took a quick look 
> and this looks like similar work to lazy image loading, but should be much 
> easier to implement now the building blocks are there.
> 
> Finally there is the task of setting threshold viewport distance values for 
> triggering deferred loads. I only have access to iOS simulator, so I wonder 
> if that is something Apple could help with?
> 
> I do not have a strong preference among these tasks. Thoughts?
> Cheers,
> 
> Rob.
> 
> P.S: I intend to attend the WebKit Contributors meeting, so feel free to chat 
> with me there about lazy loading.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Thomas Steiner]

On Mon 28. Oct 2019 at 20:02 Simon Fraser  wrote:

> > On Oct 28, 2019, at 11:39 AM, Rob Buis  wrote:
> >
> > Hi,
> >
> > I made a lazy image loading prototype earlier this year (
> https://bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting
> it up into reviewable patches. The main implementation part landed recently
> so I am wondering about the next steps.
> >
> > One thing left to do for sure is cleaning up/adding tests. For one there
> are tests in http/tests/lazyload which can just be WPT tests, so I'll work
> in this area for sure. As usual, while adding new tests bugs may show up
> and more patches will be needed.
> >
> > Another possible task is implementing metadata fetch, but it makes the
> code more complex and chromium has backtracked from it.
> >
> > Changing the behavior of loading=auto to make lazy loading the default
> seems risky and should possibly only be done when lazy image loading is
> deemed stable enough.
>
> Agreed. Is there any compat data from other browsers?
>
> >
> > 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.
> >
> > A related task is implementing lazy loading for iframe's, I took a quick
> look and this looks like similar work to lazy image loading, but should be
> much easier to implement now the building blocks are there.
>
> I think this one has the highest potential to give big page loading gains,
> especially if we can get this one turned on by default (or maybe for
> cross-origin frames), so I suggest working on this.
>
> Do we have any data from other browsers to know whether enabling
> lazy-loading iframe by default breaks the web?


We on the Chrome team have rolled this out to Lite Mode users recently and,
as far as I can tell, haven’t seen any breakage:
https://blog.chromium.org/2019/10/automatically-lazy-loading-offscreen.html.
You can contact the blog post authors for more background if need be.


>
> >
> > Finally there is the task of setting threshold viewport distance values
> for triggering deferred loads. I only have access to iOS simulator, so I
> wonder if that is something Apple could help with?
>
> I would be happy to help.
>
> >
> > I do not have a strong preference among these tasks. Thoughts?
> > Cheers,
> >
> > Rob.
> >
> > P.S: I intend to attend the WebKit Contributors meeting, so feel free to
> chat with me there about lazy loading.
>
> See you there!
>
> Simon
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
hTtPs://xKcd.cOm/1181/
-END PGP SIGNATURE-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Simon Fraser]

> On Oct 28, 2019, at 11:39 AM, Rob Buis  wrote:
> 
> Hi,
> 
> I made a lazy image loading prototype earlier this year 
> (https://bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting it 
> up into reviewable patches. The main implementation part landed recently so I 
> am wondering about the next steps.
> 
> One thing left to do for sure is cleaning up/adding tests. For one there are 
> tests in http/tests/lazyload which can just be WPT tests, so I'll work in 
> this area for sure. As usual, while adding new tests bugs may show up and 
> more patches will be needed.
> 
> Another possible task is implementing metadata fetch, but it makes the code 
> more complex and chromium has backtracked from it.
> 
> Changing the behavior of loading=auto to make lazy loading the default seems 
> risky and should possibly only be done when lazy image loading is deemed 
> stable enough.

Agreed. Is there any compat data from other browsers?

> 
> 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.
> 
> A related task is implementing lazy loading for iframe's, I took a quick look 
> and this looks like similar work to lazy image loading, but should be much 
> easier to implement now the building blocks are there.

I think this one has the highest potential to give big page loading gains, 
especially if we can get this one turned on by default (or maybe for 
cross-origin frames), so I suggest working on this.

Do we have any data from other browsers to know whether enabling lazy-loading 
iframe by default breaks the web?

> 
> Finally there is the task of setting threshold viewport distance values for 
> triggering deferred loads. I only have access to iOS simulator, so I wonder 
> if that is something Apple could help with?

I would be happy to help.

> 
> I do not have a strong preference among these tasks. Thoughts?
> Cheers,
> 
> Rob.
> 
> P.S: I intend to attend the WebKit Contributors meeting, so feel free to chat 
> with me there about lazy loading.

See you there!

Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unprefix -webkit-clip-path

[Simon Fraser]

I support unprefixing!

Simon

> On Oct 28, 2019, at 11:55 AM, Dirk Schulze  wrote:
> 
> Hi,
> 
> I didn’t hear any objections to unprefix -webkit-clip-path. Unless no new 
> concerns get raised, I’ll land the patch later this week.
> 
> Greetings,
> Dirk
> 
>> On 21. Oct 2019, at 13:01, Dirk Schulze > > wrote:
>> 
>> Hi,
>> 
>> I’d like to unprefix the -webkit-clip-path implementation.
>> 
>> The spec for clip-path is CSS Masking
>> ED: https://drafts.fxtf.org/css-masking-1/ 
>> 
>> CR: https://www.w3.org/TR/css-masking-1/ 
>> 
>> 
>> Currently, WebKit has 2 independent(!) implementations:
>> 1. The SVG clip-path CSS property that only applies to SVG elements and only 
>> allows referencing of clipPath SVG elements.
>> 2. The -webkit-clip-path CSS property that started with basic shapes (CSS 
>> shape functions) and added support for referencing of clipPath SVG elements. 
>> While initially it just worked on HTML elements it covers SVG elements as 
>> well now.
>> 
>> Therefore, the -webkit-clip-path implementation is a superset of the 
>> clip-path implementation and I intend to replace the latter with the former 
>> entirely. -webkit-clip-path will get an alias for clip-path.
>> 
>> “Unprefixing" clip-path (ship with newly supported features) has been in 
>> discussion at Mozilla as well:
>> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/clip-path%7Csort:date/mozilla.dev.platform/X29xtxQRPJc/4k1avpSxDQAJ
>>  
>> 
>> https://groups.google.com/forum/#!msg/mozilla.dev.platform/RM5O36MZ4x4/mU0cOsT7EgAJ
>>  
>> 
>> 
>> Main concern was the confusion around the path() CSS shape function which 
>> was the only CSS shape function not defined in CSS Shapes Level 1 (but 
>> defined in the Motion spec). As a result, the CSS WG moved the function to 
>> CSS Shapes Level 1 which should address the concerns of the Mozilla 
>> community.
>> 
>> The work happens here: https://bugs.webkit.org/show_bug.cgi?id=187888 
>> 
>> 
>> There are a few low-priority issues left (see master bug 
>> https://bugs.webkit.org/show_bug.cgi?id=126207 
>> ). They should not have a 
>> real-world affect though as they are corner cases.
>> 
>> Please raise your concerns here on the mailing list or send your support.
>> 
>> Thanks a lot,
>> Dirk Schulze
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unprefix -webkit-clip-path

[Dirk Schulze]

Hi,

I didn’t hear any objections to unprefix -webkit-clip-path. Unless no new 
concerns get raised, I’ll land the patch later this week.

Greetings,
Dirk

On 21. Oct 2019, at 13:01, Dirk Schulze 
mailto:dschu...@adobe.com>> wrote:

Hi,

I’d like to unprefix the -webkit-clip-path implementation.

The spec for clip-path is CSS Masking
ED: https://drafts.fxtf.org/css-masking-1/
CR: https://www.w3.org/TR/css-masking-1/

Currently, WebKit has 2 independent(!) implementations:
1. The SVG clip-path CSS property that only applies to SVG elements and only 
allows referencing of clipPath SVG elements.
2. The -webkit-clip-path CSS property that started with basic shapes (CSS shape 
functions) and added support for referencing of clipPath SVG elements. While 
initially it just worked on HTML elements it covers SVG elements as well now.

Therefore, the -webkit-clip-path implementation is a superset of the clip-path 
implementation and I intend to replace the latter with the former entirely. 
-webkit-clip-path will get an alias for clip-path.

“Unprefixing" clip-path (ship with newly supported features) has been in 
discussion at Mozilla as well:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/clip-path%7Csort:date/mozilla.dev.platform/X29xtxQRPJc/4k1avpSxDQAJ
https://groups.google.com/forum/#!msg/mozilla.dev.platform/RM5O36MZ4x4/mU0cOsT7EgAJ

Main concern was the confusion around the path() CSS shape function which was 
the only CSS shape function not defined in CSS Shapes Level 1 (but defined in 
the Motion spec). As a result, the CSS WG moved the function to CSS Shapes 
Level 1 which should address the concerns of the Mozilla community.

The work happens here: https://bugs.webkit.org/show_bug.cgi?id=187888

There are a few low-priority issues left (see master bug 
https://bugs.webkit.org/show_bug.cgi?id=126207). They should not have a 
real-world affect though as they are corner cases.

Please raise your concerns here on the mailing list or send your support.

Thanks a lot,
Dirk Schulze

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Lazy loading

[Rob Buis]

Hi,

I made a lazy image loading prototype earlier this year 
(https://bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting 
it up into reviewable patches. The main implementation part landed 
recently so I am wondering about the next steps.


One thing left to do for sure is cleaning up/adding tests. For one there 
are tests in http/tests/lazyload which can just be WPT tests, so I'll 
work in this area for sure. As usual, while adding new tests bugs may 
show up and more patches will be needed.


Another possible task is implementing metadata fetch, but it makes the 
code more complex and chromium has backtracked from it.


Changing the behavior of loading=auto to make lazy loading the default 
seems risky and should possibly only be done when lazy image loading is 
deemed stable enough.


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.


A related task is implementing lazy loading for iframe's, I took a quick 
look and this looks like similar work to lazy image loading, but should 
be much easier to implement now the building blocks are there.


Finally there is the task of setting threshold viewport distance values 
for triggering deferred loads. I only have access to iOS simulator, so I 
wonder if that is something Apple could help with?


I do not have a strong preference among these tasks. Thoughts?
Cheers,

Rob.

P.S: I intend to attend the WebKit Contributors meeting, so feel free to 
chat with me there about lazy loading.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev