[Bug 20246] Provide a system to observe nodes entering and leaving the viewport

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20246

Simon Pieters <simonp@opera.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simonp@opera.com

--- Comment #10 from Simon Pieters <simonp@opera.com> ---
I can see these use cases stated here:

1. Lazy loading of images that are not initially visible.
2. Pausing animations with requestAnimationFrame or CSS animations if an
element is not currently visible for better performance or to not drain the
user's battery.
3. Removing elements that are no longer visible to release memory.

(1) seems to be what the lazyload="" attribute is intended to address. Is that
sufficient?

The ViewportObserver API seems like a bad solution to this use case since
images are fetched before scripts run, so it is better to have a declarative
way to delay fetching of images. Also, it seems to me that it would be a bad
user experience to start fetching an image after it has entered the viewport.
It would be better to fetch it before it has entered the viewport. The user
agent is probably in a better position than the author to decide when to fetch
a lazy image.

(2) Jake Archibald suggests that requestAnimationFrame should handle this with
a second parameter. Would that be sufficient? Has that been proposed to the
relevant WG?

Pausing CSS animations that are not currently visible seems like something that
user agents can do without help from the author.

(3) It seems to me that browsers could optimize this without having the author
removing and inserting elements while scrolling. In fact, I can imagine that
removing and inserting elements while scrolling can make things worse.

I'm not saying that the proposed feature should not be added. However, there
are several proposals that seem to address the stated use cases. We need to
evaluate which best address the use cases.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 25 June 2013 15:27:06 UTC