Open ehsan-karamad opened 6 years ago
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)
.
Thanks you are right. I fixed the missing single quotes for self
.
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 ?
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
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
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.
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
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).
Closed by accident :).
So, this feature is about the full right to use the
lazyload
attribute (and essentially theoff
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 thelazyload
attribute value tooff
. If they did there will be enforcement (i.e.,off
changes toauto
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'.
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>
.
loading="eager"
? Not allow="loading-frame-default-eager *"
?
@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 forloading
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
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 forloading
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.
@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
.
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?
Should this be revisited, in light of the Permissions-Policy → Document-Policy/Structured Headers changes?
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 islazyload
.The
lazyload
attribute (for an<iframe>
or<img>
) takes on three values ofauto
(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 oflazyload
attribute is not altered (user agent decides) .off
: the default behavior oflazyload
is set tooff
. For example, if the sitewww.example.com
sets its header policy toFeature Policy: lazyload 'self'(off)
, thenwill still load the contents lazily due to the defined attributes, but
will not load the contents lazily since the feature is set to
off
by default.force
: ignores the value oflazyload
attribute and enforces it toon
for all<iframe>
and<img>
. For example, if a site sets its header policy toFeature Policy: lazyload *(force)
then all<iframe>
's and<img>
's from all domains will be loaded lazily. For example inthe 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 thelazyload
feature, such a usage may trigger a violation error.The feature can also be set through container policies, for instance:
which will enforce lazy loading for all domains. This would include
https://www.example.com
.