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

Lazyload images #3752

Merged
merged 8 commits into from Feb 12, 2020
Merged

Lazyload images #3752

merged 8 commits into from Feb 12, 2020

Conversation

@bengreenstein
Copy link
Contributor

@bengreenstein bengreenstein commented Jun 8, 2018

@domenic

This is a draft of spec changes to support a lazyload attribute in iframe and img elements.


Issue: #2806
Tests: https://chromium-review.googlesource.com/c/chromium/src/+/1417117 (wpt export)


/embedded-content.html ( diff )
/images.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/media.html ( diff )
/rendering.html ( diff )
/urls-and-fetching.html ( diff )

@domenic
Copy link
Member

@domenic domenic commented Jun 12, 2018

I did another minor pass; PTAL.

Copy link
Member

@domenic domenic left a comment

Some issues with the metadata fetcher

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
Copy link
Member

@domenic domenic left a comment

Metadata fetching looks good to me editorially now. Eager to hear others thoughts on whether it provides the right foundation for interoperability.

@domenic domenic dismissed their stale review Jun 28, 2018

Things were fixed

Copy link
Member

@annevk annevk left a comment

You also need to update the element indexes to include this attribute for img and iframe.

Should this influence https://fetch.spec.whatwg.org/#concept-request-priority somehow?

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@jakearchibald jakearchibald self-requested a review Jul 25, 2018
Copy link
Collaborator

@jakearchibald jakearchibald left a comment

Also: img.decode() waits for the image fetch to complete. With lazyload, this may take a long time, or might never happen. Is that the intent? Feels like decode() is a strong signal that the developer wants the image to fetch.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated
<tr>
<td><dfn><code data-x="attr-lazyload-auto">auto</code></dfn>
<td><dfn data-x="attr-lazyload-auto-state">Auto</dfn>
<td>Indicates that the user agent may determine the fetching strategy (the default).

This comment has been minimized.

@jakearchibald

jakearchibald Jul 25, 2018
Collaborator

I think there are cases where we need to define 'auto'. Expectations are pretty strong when it comes to new Image(). Perhaps "off" is the default unless the image was created by the regular document parser (not innerHTML and createContextualFragment).

This comment has been minimized.

@domenic

domenic Dec 18, 2018
Member

I'm in favor of leaving auto free to experiment for now...

This comment has been minimized.

@zcorpan

zcorpan Mar 6, 2019
Member

new Audio() sets preload=auto, maybe new Image() could set load=eager to match expectations.

source Outdated

<p>A <dfn>lazy loading attribute</dfn> is an <span>enumerated attribute</span>. The following
table lists the keywords and states for the attribute &mdash; the keywords in the left column map
to the states in the cell in the second column on the same row as the keyword.</p>

This comment has been minimized.

@jakearchibald

jakearchibald Jul 25, 2018
Collaborator

What happens if this value is changed after element creation? Eg, if I switch from "on" to "off". Feels like the image should immediately load. Worth spelling out?

This comment has been minimized.

@domenic

domenic Dec 18, 2018
Member

This is explicit in the spec's

user agents must obtain images immediately when the CSS boxes those images intersect the viewport, or when the corresponding img element's lazyload attribute is in the Off state

But maybe we can add a clarifying note right after that paragraph, saying "This means that if the author changes the lazyload attribute's value to Off, and the image has not already been obtained, it will immediately be obtained."

This comment has been minimized.

@zcorpan

zcorpan Mar 6, 2019
Member

This seems like a possibly common use case. Is it clear that changing the state is the way to load the image, or should there be a load() method (like for media elements)?

This comment has been minimized.

@zcorpan

zcorpan Mar 6, 2019
Member

I just realized that load() would conflict with load IDL attribute...

aarongable pushed a commit to chromium/chromium that referenced this pull request Aug 16, 2018
This CL implements support for the "lazyload" attribute on frames,
according to whatwg/html#3752, and as part of
the LazyLoad feature. The accepted values are:

"on", which causes the browser to lazily load a frame even if it's
same-origin or nested inside another lazyloaded frame,

"off", which causes the browser to avoid lazily loading this frame or
any of it's children (unless those children are marked with
lazyload="on"),

"auto", which activates the default behavior, and is therefore not
explicitly handled in code.

Bug: 873358
Change-Id: I2fde65adb15216260291b08e39888a2363f44d4a
Reviewed-on: https://chromium-review.googlesource.com/1176293
Commit-Queue: Scott Little <sclittle@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583841}
aarongable pushed a commit to chromium/chromium that referenced this pull request Sep 19, 2018
This CL implements support for the "lazyload" attribute on images,
according to whatwg/html#3752, and as part of
the LazyLoad feature. The accepted values are:

"off", which causes the browser to avoid lazily loading the <img> element

"on" and "auto", activate the default behavior of lazily load the <img> element

When the attribute is changed to "off", the deferred image loads immediately.

Bug: 875080
Change-Id: I839926a9827d019f23aafc40f8315476fe1b3048
Reviewed-on: https://chromium-review.googlesource.com/1197782
Reviewed-by: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: rajendrant <rajendrant@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592599}
Copy link
Member

@sideshowbarker sideshowbarker left a comment

I’d suggest that since the change to the CONTRIBUTING.md and README.md files arenn’t directly related to the substance of the rest of this patch (lazyload feature), it’d be preferable for the CONTRIBUTING.md and README.md changes to be in separate patches from this patch. It’d be fine if they are just a separate commits as part of PR #3752 but not sure if that would happen, given that the policy here for PRs is that they result in a single (squashed) commit that gets merged to master

Copy link
Member

@sideshowbarker sideshowbarker left a comment

The changes to dev/style.css for adding the syntax-highlighter styles have already been merged into master, so they should be dropped from this patch.

Copy link
Member

@sideshowbarker sideshowbarker left a comment

OK, I’m now realizing that this reason some unrelated changes are showing up in the diff here are that this patch includes some merges? So it seems like it needs to be rebased against master to clear those away?

@bengreenstein bengreenstein force-pushed the bengreenstein:lazyloading branch from d2af159 to da6a6f8 Oct 2, 2018
@annevk
Copy link
Member

@annevk annevk commented Dec 11, 2018

@bengreenstein could you rebase this against master and then force push the resulting changeset to get rid of the merge commits? As it stands it looks like this is proposing a number of changes against dev/styles.css for instance, which doesn't seem correct.

@sideshowbarker
Copy link
Member

@sideshowbarker sideshowbarker commented Dec 14, 2018

This branch is now in a state that it can’t be rebased against master without multiple merge conflicts.

@bengreenstein bengreenstein force-pushed the bengreenstein:lazyloading branch from b2cdf21 to c093e8c Dec 14, 2018
@bengreenstein
Copy link
Contributor Author

@bengreenstein bengreenstein commented Dec 14, 2018

@sideshowbarker and @annevk Sorry about the state of the branch. Hopefully now it is all cleaned up.

Copy link
Member

@domenic domenic left a comment

Some stuff to work out around images; I'm most concerned about srcset/picture.

Will look through other reviewers' comments and flag them also.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
Copy link
Member

@domenic domenic left a comment

Small things and one big thing: what to do for srcset and picture.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@domenic
Copy link
Member

@domenic domenic commented Dec 21, 2018

OK, sweet! I pushed up a few minor tweaks of my own, almost all editorial. This now looks good to me.

@jakearchibald, I think we addressed your comments, so I will dismiss your review, but if you have the time, a re-review would be much appreciated.

From what I recall, this had pretty active and helpful support from WebKit at least in #2806. @smfr and/or @othermaciej, would you like to take a look at the results, probably using the diff links in the OP to see the rendered additions? From what I can see we haven't yet addressed the WebKit request to have a feature for a placeholder image while it is loading ("lowsrc"), but I think we went through a lot of the other questions in that thread and resolved them; please correct me if I'm wrong.

@bengreenstein, are there web platform tests for this yet?

@domenic domenic added the needs tests label Dec 21, 2018
@domenic domenic dismissed jakearchibald’s stale review Dec 21, 2018

Comments addressed, I think!

@BitPopCoin
Copy link

@BitPopCoin BitPopCoin commented Jan 11, 2019

I'd like a call back I can insert into an anchor or something to let me know when a location has been reached.

aarongable pushed a commit to chromium/chromium that referenced this pull request Jan 11, 2019
In previous CLs, support for the lazyLoad attribute was added, but the
corresponding idl attribute entries were mistakely forgotten. This CL
adds those attribute entries, making it possible to detect if the
browser supports native lazy loading from JavaScript.

Spec: whatwg/html#3752
ChromeStatus entry: https://www.chromestatus.com/feature/5645767347798016
Intent to implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/czmmZUd4Vww/1-H6j-zdAwAJ

Bug: 913162
Change-Id: Ib801c376ac70bf14eb2779e1642409f9cf03a95d
Reviewed-on: https://chromium-review.googlesource.com/c/1372534
Commit-Queue: Scott Little <sclittle@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#622203}
@annevk
Copy link
Member

@annevk annevk commented Feb 10, 2020

That doesn't return anything for me. web-platform-tests PRs or paths to tests would be good to have and ideally we include as many of those as possible.

@domfarolino
Copy link
Member

@domfarolino domfarolino commented Feb 12, 2020

Sorry about that, I just realized the URL had some mentions of self, which would only work for an authenticated user's POV. Major test PRs are as follows (in order of merging):

There are some refactorings and corrections made in between them, but the above links are the more-major works.

@annevk
Copy link
Member

@annevk annevk commented Feb 12, 2020

Thank you! It seems that #4655 should be addressed still. Unfortunately that wasn't made as a comment against this PR and I found it rather late while trying to come up with a commit message.

Copy link
Member

@zcorpan zcorpan left a comment

I think this is ready, and doesn't need to be blocked on #4655

@annevk annevk merged commit 0283e9e into whatwg:master Feb 12, 2020
2 checks passed
2 checks passed
Participation bengreenstein participates on behalf of Google LLC
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@annevk
Copy link
Member

@annevk annevk commented Feb 12, 2020

Huge thanks to @domfarolino for making this happen and everyone who gave feedback and helped out along the way! Looking forward to faster page loads.

rwlbuis added a commit to web-platform-tests/wpt that referenced this pull request Feb 13, 2020
whatwg/html#3752 landed, so
remove comments and tentative extension.
rwlbuis added a commit to web-platform-tests/wpt that referenced this pull request Feb 13, 2020
whatwg/html#3752 landed, so
remove comments and tentative extension.
rwlbuis added a commit to web-platform-tests/wpt that referenced this pull request Feb 13, 2020
whatwg/html#3752 landed, so
remove comments and tentative extension.
rwlbuis added a commit to web-platform-tests/wpt that referenced this pull request Feb 13, 2020
whatwg/html#3752 landed, so
remove comments and tentative extension.
@jonathanhefner jonathanhefner mentioned this pull request Feb 13, 2020
2 of 2 tasks complete
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Feb 17, 2020
…=testonly

Automatic update from web-platform-tests
Remove tentative from lazy load tests (#21773)

whatwg/html#3752 landed, so
remove comments and tentative extension.
--

wpt-commits: 283eaa796815403a3e959861f6f1e61b0d35848f
wpt-pr: 21773


--HG--
rename : testing/web-platform/tests/loading/lazyload/common.js => testing/web-platform/tests/html/semantics/embedded-content/the-img-element/common.js
rename : testing/web-platform/tests/loading/lazyload/disconnected-image-loading-lazy.tentative.html => testing/web-platform/tests/html/semantics/embedded-content/the-img-element/disconnected-image-loading-lazy.html
rename : testing/web-platform/tests/loading/lazyload/resources/image-loading-lazy-below-viewport-iframe.html => testing/web-platform/tests/html/semantics/embedded-content/the-img-element/resources/image-loading-lazy-below-viewport-iframe.html
rename : testing/web-platform/tests/loading/lazyload/resources/image-loading-lazy-in-viewport-iframe.html => testing/web-platform/tests/html/semantics/embedded-content/the-img-element/resources/image-loading-lazy-in-viewport-iframe.html
rename : testing/web-platform/tests/loading/lazyload/resources/image.png => testing/web-platform/tests/html/semantics/embedded-content/the-img-element/resources/image.png
rename : testing/web-platform/tests/loading/lazyload/resources/newwindow.html => testing/web-platform/tests/html/semantics/embedded-content/the-img-element/resources/newwindow.html
rename : testing/web-platform/tests/loading/lazyload/resources/referrer-checker-img.py => testing/web-platform/tests/html/semantics/embedded-content/the-img-element/resources/referrer-checker-img.py
rename : testing/web-platform/tests/loading/lazyload/resources/subframe.html => testing/web-platform/tests/html/semantics/embedded-content/the-img-element/resources/subframe.html
xeonchen pushed a commit to xeonchen/gecko that referenced this pull request Feb 18, 2020
…=testonly

Automatic update from web-platform-tests
Remove tentative from lazy load tests (#21773)

whatwg/html#3752 landed, so
remove comments and tentative extension.
--

wpt-commits: 283eaa796815403a3e959861f6f1e61b0d35848f
wpt-pr: 21773
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment