W3C home > Mailing lists > Public > www-style@w3.org > April 2016

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 6 Apr 2016 10:47:22 -0700
Message-ID: <CAAWBYDBwuZ-hQU4H5gRXHt9kA49QwA6RAM-TbeKCHcRfOWnhMQ@mail.gmail.com>
To: Matt Woodrow <mwoodrow@mozilla.com>
Cc: "www-style@w3.org" <www-style@w3.org>, Kartikaya Gupta <kgupta@mozilla.com>
On Wed, Apr 6, 2016 at 4:11 AM, Matt Woodrow <mwoodrow@mozilla.com> wrote:
> I'd like to propose exposing the 'renderport' to web content, defined as the
> area of a scrollable container that is actually rendered by the UA, which
> may be larger than the viewport (visible) area.
> Most browsers these days are rendering areas larger than what is currently
> visible (especially, but not limited to the root scrollframe) to allow
> asynchronous scrolling.
> We also have a lot examples (especially on mobile) of web content that
> dynamically adds and removes content based on the scroll position (referred
> to as 'data scrollers' in the IntersectionObserver spec).
> Both of these systems are independently maintaining a definition of what is
> 'soon to be visible', and when they aren't in sync we get sub-optimal
> performance. If the data scroller chooses an area larger than the UA, then
> they are bloating the DOM unnecessarily, which is what they are trying to
> avoid. If the data scroller chooses an area smaller than the UA, then we get
> unnecessary invalidations and repeated drawing of the same pixels.
> Our suggested solution to this is to add a callback to scrollable elements
> that fires before painting (similar to requestAnimationFrame) and exposes
> the (approximate) region of the element that the UA is going to treat as
> visible for the purpose of painting.
> DOM changes from within the callback that result in the final renderport
> area changing probably shouldn't trigger another callback until after the
> paint to avoid infinite loops.
> It might also be nice to extend the IntersectionObserver spec to allow
> specifying the renderport (plus a margin) as the intersection region to
> observe, so that content can trigger asynchronous loading of data before it
> enters the renderport, but that can wait until we make a decision on this.

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

Received on Wednesday, 6 April 2016 17:48:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC