- From: Matt Woodrow <mwoodrow@mozilla.com>
- Date: Thu, 7 Apr 2016 13:47:15 +1200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "www-style@w3.org" <www-style@w3.org>, Kartikaya Gupta <kgupta@mozilla.com>
On 7/04/16 5:47 AM, Tab Atkins Jr. wrote: > Either or both of these seem fairly sensible to me at first glance. > Should we try to stick with just one, or are there good reasons for > both? ~TJ I think they're both fairly useful. IntersectionObserver provides asynchronous notifications when an area of interest become visible. Attempts to replace placeholder content with the real thing will either happen too late (and the browser has already rendered the placeholder), or rely on guesswork (using pixel margins). Providing a synchronous callback to share information that the browser already has seems like a significant improvement. Adding renderport to IntersectionObserver would be useful for content that wants to do an asynchronous fetch of the new data before adding it to the DOM. They're already making a guess on how long the fetch will take, so guessing a pixel margin for the observer isn't a problem. If they're using the renderport callback to add their content to the DOM, they will want the intersection observer notification to be relative to that, not relative to the viewport. This definitely seems like a 'nice to have' extension to the former feature, and probably isn't that useful on its own. - Matt
Received on Thursday, 7 April 2016 01:47:51 UTC