-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Add support for video element lazy-loading via the loading attribute #11980
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
base: main
Are you sure you want to change the base?
Conversation
Specify support for the loading attribute for video using similar conventions to img and iframe, where the attribute has precedent. It has possible values of eager and lazy. When the loading attribute value is lazy, loading of any video or poster image data, as well as autoplay playback, must defer until layout is known and the video is in the viewport. This commit contains examples for how the loading attribute should take precedence over the preload, poster, and autoplay attributes. These were informed by experiments with local patch implementations to several user agents.
|
cc @whatwg/media |
|
|
||
| <li><p>If <var>resumptionSteps</var> is null, then return.</p></li> | ||
|
|
||
| <li><p>Set the <code>video</code>'s <span>lazy load resumption steps</span> to null.</p></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is video's lazy load resumption steps set to a non-null value? Is a call to "start intersection-observing a lazy loading element" needed somewhere to make it all work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this. I'll be following up shortly with a commit that'll define these steps in a few areas relevant to video (fetching, autoplay, poster, preload).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@foolip Thanks again. In the latest commit to this PR, I've attempted to fill in missing steps when loading state is lazy when evaluating poster, autoplay eligibility, video resource fetching, and the steps to resume when loading state changes to eager. Happy to iterate further with any guidance you might have.
|
This direction makes sense to me, but I'm not personally able to make a commitment to implement in Chromium. @zcorpan I think you've mentioned this feature, perhaps you have feedback? |
Add detail for video element lazy loading behavior when loading state is lazy. This involves returning early to prevent poster and video data loading and defining resumption steps to resume when loading state changes to eager. Also includes notes about autoplay eligibility and precedence over the preload attribute.
Specify support for the loading attribute for video using similar conventions to img and iframe, where the attribute has precedent. It has possible values of eager and lazy. When the loading attribute value is lazy, loading of any video or poster image data, as well as autoplay playback, must defer until layout is known and the video is in the viewport. This commit contains examples for how the loading attribute should take precedence over the preload, poster, and autoplay attributes. These were informed by experiments with local patch implementations to several user agents.
Addresses #10376
(See WHATWG Working Mode: Changes for more details.)
/acknowledgements.html ( diff )
/indices.html ( diff )
/media.html ( diff )
/urls-and-fetching.html ( diff )