Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Policy: lazyload #6

Open
ehsan-karamad opened this issue Jul 30, 2018 · 15 comments
Open

Feature Policy: lazyload #6

ehsan-karamad opened this issue Jul 30, 2018 · 15 comments

Comments

@ehsan-karamad
Copy link

@ehsan-karamad ehsan-karamad commented Jul 30, 2018

Proposing a new feature policy for lazy-loading which will overwrite the default or specified behavior of lazyload attribute for <iframe> and <img>. The proposed name for the feature is lazyload.

The lazyload attribute (for an <iframe> or <img>) takes on three values of auto (decision of lazy-loading is deferred to the user agent), on (the contents will be loaded lazily), off (the contents will not be loaded lazily).

The proposed lazyload feature is a parameterized feature which takes one of the three values of:

  • auto: the default behavior of lazyload attribute is not altered (user agent decides) .
  • off: the default behavior of lazyload is set to off.
    For example, if the site www.example.com sets its header policy to Feature Policy: lazyload 'self'(off), then
 <iframe src="https://www.example.com/a" lazyload="on"></iframe>

will still load the contents lazily due to the defined attributes, but

<iframe src="https://www.example.com/b"></iframe>

will not load the contents lazily since the feature is set to off by default.

  • force: ignores the value of lazyload attribute and enforces it to on for all <iframe> and <img> .
    For example, if a site sets its header policy to Feature Policy: lazyload *(force) then all <iframe>'s and <img>'s from all domains will be loaded lazily. For example in
<iframe src="http://www.example.com/" lazyload="off"></iframe>

the provided attributed is ignored and the contents will be loaded lazily due to policy enforcement. Also, since the lazyload attribute setting is in violation of the lazyload feature, such a usage may trigger a violation error.

The feature can also be set through container policies, for instance:

<iframe allow="lazyload *(force)" src="https://www.example.com" lazyload="off"></iframe>

which will enforce lazy loading for all domains. This would include https://www.example.com.

@Malvoz
Copy link

@Malvoz Malvoz commented Jul 31, 2018

Just to clarify, I believe you missed the single quotes for the self and none values. And I would assume we set (auto|off|force) flags outside the single quotes? e.g. Feature Policy: lazyload 'self'(force) and the all (*) directive like so: Feature Policy: lazyload *(force).

@ehsan-karamad
Copy link
Author

@ehsan-karamad ehsan-karamad commented Jul 31, 2018

Thanks you are right. I fixed the missing single quotes for self.

@alvarotrigo
Copy link

@alvarotrigo alvarotrigo commented Nov 16, 2018

Any way to detect whether the browser supports this feature or not?
So we can use other lazy load libraries in case it doesn't ?

@triblondon
Copy link

@triblondon triblondon commented Feb 2, 2019

Doesn't this feature have a really confusing name? I'm reading https://github.com/w3c/webappsec-feature-policy/blob/master/policies/lazyload.md, where it says:

Feature Policy: lazyload 'self' https://example.com
would not allow synchronous loading for any <iframe> or (that is not yet in the viewport) from origins other than 'self' or https://example.com.

So, wait, if I apply the lazyload policy to example.com, then everything except example.com enforces lazy loading? I read it like 6 times and I can't see how that makes any sense...

Suggestions: greedy-load, preload-offscreen

@ehsan-karamad
Copy link
Author

@ehsan-karamad ehsan-karamad commented Feb 4, 2019

Any way to detect whether the browser supports this feature or not?
So we can use other lazy load libraries in case it doesn't ?

I think on Chrome 74 with "Experimental Web Platform" flag off, |el.lazyload| would return undefined. However, it would return auto if the flag is on.

@ehsan-karamad
Copy link
Author

@ehsan-karamad ehsan-karamad commented Feb 4, 2019

Doesn't this feature have a really confusing name?

I agree the name is confusing; it is supposed to suggest the full control over the lazyload attribute, i.e., of disabled you cannot do certain things. Another alternative we are thinking is the termeager-loading. I like the preload-offscreen as well since it is very descriptive of what the policy does.

I'm reading https://github.com/w3c/webappsec-feature-policy/blob/master/policies/lazyload.md, where it says:
Feature Policy: lazyload 'self' https://example.com
would not allow synchronous loading for any <iframe> or (that is not yet in the viewport) from origins other than 'self' or https://example.com.

So, wait, if I apply the lazyload policy to example.com, then everything except example.com enforces lazy loading? I read it like 6 times and I can't see how that makes any sense...

Suggestions: greedy-load, preload-offscreen

So, this feature is about the full right to use the lazyload attribute (and essentially the off state) on <img> and <iframe> elements. This means if the feature is disabled for an origin, then the origin cannot avoid lazyloading some content by setting the lazyload attribute value to off. If they did there will be enforcement (i.e., off changes to auto and browser decides what is best to do) and a policy violation report is generated.

For the specific example, if a website would define

Feature Policy: lazyload http://example.com

then any embedded content from http://example.com is allowed to use lazyload=off on its own <img> and <iframe> elements. However if the website embeds a http://foo.com which tries to do that they would end up violating the feature (e.g., lazyload enforced and a violation report is generated).

@ehsan-karamad
Copy link
Author

@ehsan-karamad ehsan-karamad commented Feb 4, 2019

Closed by accident :).

@ehsan-karamad ehsan-karamad reopened this Feb 4, 2019
@triblondon
Copy link

@triblondon triblondon commented Feb 4, 2019

So, this feature is about the full right to use the lazyload attribute (and essentially the off state) on <img> and <iframe> elements. This means if the feature is disabled for an origin, then the origin cannot avoid lazyloading some content by setting the lazyload attribute value to off. If they did there will be enforcement (i.e., off changes to auto and browser decides what is best to do) and a policy violation report is generated.

Yes, I understand that, but that's because I've read it six times :-) I really hope we can rename. eager-loading would work but sounds a bit too positive, so I would worry that people would throw it in thinking it sounded like a best practice. If you like preload-offscreen that sounds like a good option, as long as the semantics of the 'lazyload' attribute continue to be about viewport intersection, which is explicit in the naming of 'preload-offscreen' but not in 'lazyload'.

@ehsan-karamad
Copy link
Author

@ehsan-karamad ehsan-karamad commented Apr 17, 2019

There is a PR which would rework and rename the proposed lazyload policy. The new policy modifies the default/auto behavior of the loading attribute. The new name is loading-frame-default-eager and by turning it off, the <iframe>s inside the document will not load eagerly unless they have loading="eager" explicitly set. A similar policy should be proposed for <img>.

@triblondon
Copy link

@triblondon triblondon commented Apr 24, 2019

loading="eager"? Not allow="loading-frame-default-eager *"?

@Malvoz
Copy link

@Malvoz Malvoz commented Aug 19, 2019

@ehsan-karamad

Both the loading-frame-default-eager.md and loading-image-default-eager.md documents seem to be missing some sentencing in the "What does this mean" section:

With the loading-frame-default-eager policy, developers could prioritize the loading of different inline frames on a web page. This however could become a cumbersome process and not quite scalable for larger web sites; specially given that applying the attribute is origin-agnostic. The proposed policy aims to resolve this issue by changing a browser's default decision for loading behavior.

I think before the sentence: "This however could become a cumbersome process [...]" it should be explained that (e.g) "Developers may use the loading attribute to specify the loading behavior of an {image|iframe}.".

Is that correct? If so, I can PR unless you want to do it.

@ehsan-karamad
Copy link
Author

@ehsan-karamad ehsan-karamad commented Aug 19, 2019

@ehsan-karamad

Both the loading-frame-default-eager.md and loading-image-default-eager.md documents seem to be missing some sentencing in the "What does this mean" section:

With the loading-frame-default-eager policy, developers could prioritize the loading of different inline frames on a web page. This however could become a cumbersome process and not quite scalable for larger web sites; specially given that applying the attribute is origin-agnostic. The proposed policy aims to resolve this issue by changing a browser's default decision for loading behavior.

I think before the sentence: "This however could become a cumbersome process [...]" it should be explained that (e.g) "Developers may use the loading attribute to specify the loading behavior of an {image|iframe}.".

Is that correct? If so, I can PR unless you want to do it.

Thanks for pointing this out. Yes. I believe this is would look better. Please send a PR and also have @clelland take a look.

Malvoz referenced this issue in Malvoz/feature-policy Aug 19, 2019
Malvoz referenced this issue in Malvoz/feature-policy Aug 19, 2019
@Malvoz
Copy link

@Malvoz Malvoz commented Aug 27, 2019

@RGHuhn

Yes, as stated in https://github.com/w3c/webappsec-feature-policy/issues/193#issuecomment-484109871 the lazyload policy was changed, and divided into 2 policies, namely loading-image-default-eager and loading-frame-default-eager.

@domfarolino
Copy link

@domfarolino domfarolino commented Nov 12, 2019

As @Malvoz mentioned, this policy has been split in two, so can this be closed? Also, I'm curious as to the reasoning for splitting this into image- and frame-policies in the first place. Is having one policy to control all loading=auto behavior too coarse/powerful?

@eeeps
Copy link

@eeeps eeeps commented Aug 20, 2020

Should this be revisited, in light of the Permissions-Policy → Document-Policy/Structured Headers changes?

@clelland clelland transferred this issue from w3c/webappsec-permissions-policy Dec 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants