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: Fri, 8 Apr 2016 11:55:47 -0700
Message-ID: <CAAWBYDABXfrAsOneZyJsToWnRC-EPN4L3nYw_8hr7A-FoqNFVg@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:
> Hi,
> 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.

I talked this over further with Ojan and Elliot, and I think we're
actually against this, at least as stated.

The reason is that the "area that the browser is prepainting" can vary
drastically across browsers and versions.  At the moment, our window
is *huge* (I think they said 8k by 8k or so?) but we have plans to
shrink it to only a *teensy* bit larger than the visual viewport, just
a tile row or two past the edge (but we'll be doing other work in a
larger window, like running layout on contain'd elements).  It's
likely that content will end up depending on a particular size of
window, forcing us to lie in the future.

That said, just changing the semantic a little, so it's explicitly
just the region of the scroll area that the browser recommends having
prepared, would work.  In fast inertial scrolls, it can provide the
end-point window, which would be convenient!

Received on Friday, 8 April 2016 18:56:36 UTC

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