Clarify then the check whether script is disabled for lazy-load

[hiikezoe]

Though the spec says user agents should not honor the lazy loading attribute when scripting is disabled, but as far as I can see there is no description when it's done.

I have an interesting edge case, that is that an image element which is in the state waiting for load due to 'lazy" is moved into an iframe that script is disabled there. I was guessing the image in question is not loaded on Chrome because, as per the spec text, there seems no chance to check it after the image became the state of 'will-lazy-load-image-steps', but actually Chrome does.

@domfarolino, @annevk, @emilio

[domfarolino]

A couple of things here:

• The paragraph you point to in the spec is actually non-normative, so it is not required to be implemented by browsers to be spec-compliant. This is because the sentence uses "should", whose formal definition can be found in this RFC
• Regardless, FWIW, Chrome does plan on implementing this optional anti-tracking behavior behavior: https://crbug.com/1005881
• However, Chrome currently does not implement that behavior, meaning images moved to an iframe where scripting is disabled should be able to load lazily. However, Chrome also has a bug where loading=lazy images moved to out-of-viewport iframes are automatically loaded regardless, so your test should accidentally pass in Chrome. From running it locally, I see it passing in Chrome stable and Canary, am I missing something?

[hiikezoe]

* However, Chrome currently does not implement that behavior, meaning images moved to an iframe where scripting is disabled should be able to load lazily. _However_, Chrome also has a bug where loading=lazy images moved to out-of-viewport iframes are automatically loaded regardless, so your test should accidentally pass in Chrome. From running it locally, I see it passing in Chrome stable and Canary, am I missing something?

Sorry for confusing. The test I wrote is what I believe that it should be, i.e. the loading=lazy image should be loaded in script disabled documents even if the image has already been in the state of 'will-lazy-load-image-steps'.

[domfarolino]

Ahh I see. The spec doesn't explicitly check for script-enabled-ness after the will-lazy-load-image steps are run, and since Chrome passes the test, it feels like Chrome is somehow checking whether scripting is enabled after those steps are run. However, I believe when an image is adopted into another frame, the updating-the-image-data steps are re-run (i.e., the will-lazy-load-image steps are run again).

That is an interesting scenario. Since it is a non-normative section in the spec, it is not explicitly mentioned how/when exactly a browser should perform this check in relation to the image loading algorithm steps. With that said, I'm not sure if this issue is actionable or if we can write tests for it.

[annevk]

Uhm, should is not non-normative. See also https://infra.spec.whatwg.org/#conformance. A "should" is a requirement that you can chose not to follow if you have a very good reason for not following that requirement. It's still a normative requirement and can be tested. And if everyone plans to implement it perhaps we ought to make it a "must" instead.

[domfarolino]

I see. Sorry for my misunderstanding; @hiikezoe's test would be good to add then. Feel free to submit a WPT PR.

I am happy making it a "must" if everyone plans to implement it. @annevk do you think adding a condition to "will lazy load image steps" that checks whether scripting is enabled makes sense? I think this will suffice, because after a deferred image is removed and inserted into another document, my understanding is that the #updating-the-image-data steps are re-run.

[annevk]

So it would still not delay the load event?

[domfarolino]

Correct. This should be OK from a tracking perspective, but on the other hand I like the consistency of scripting-disabled == all lazy load behavior turned off (all fetches are eager, all images delay the load event).

[domfarolino]

BTW @hiikezoe would you be willing to make a WPT PR for your test? Since we're making it very explicit in the spec that scripting must be enabled for the loading attribute to have any effect, we'll probably need your test to land :)

[hiikezoe]

@domfarolino I've already included two web platform tests for that in our lazy-load implementation bug. Those will be merged into upstream once after it landed in our tree.

[hackademix]

Note for future reference: the relevant "Lazy loading attributes" spec currently lives here, still with the note about disabling lazy when scripting is disabled:

This is an anti-tracking measure, because if a user agent supported lazy loading when scripting is disabled, it would still be possible for a site to track a user's approximate scroll position throughout a session, by strategically placing images in a page's markup such that a server can track how many images are requested and when.