Re: [cssom-view] Expose the 'renderport' to content

On Thu, 07 Apr 2016 03:47:15 +0200, Matt Woodrow <mwoodrow@mozilla.com>  
wrote:

>
> 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.

The scroll event is synced with animation frames per spec. It seems  
reasonable to update the exposed renderport as a new first substep of  
https://drafts.csswg.org/cssom-view/#run-the-scroll-steps

It seems to me it doesn't need to be a callback, it can just be exposed  
somewhere, and you would typically read it from a 'scroll' event listener?

The discussion about how to integrate this in IntersectionObserver I would  
recommend opening an issue at  
https://github.com/WICG/IntersectionObserver/issues

-- 
Simon Pieters
Opera Software

Received on Thursday, 7 April 2016 10:22:34 UTC