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

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

From: Ojan Vafai <ojan@chromium.org>
Date: Mon, 11 Apr 2016 18:13:36 +0000
Message-ID: <CANMdWTtFN_ThGe1qVHFZ+SX26E_cgZTy9jTqjdY3Yv9vbWZXzw@mail.gmail.com>
To: Matt Woodrow <mwoodrow@mozilla.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>, Kartikaya Gupta <kgupta@mozilla.com>
On Mon, Apr 11, 2016 at 3:17 AM Matt Woodrow <mwoodrow@mozilla.com> wrote:

> On 9/04/16 6:55 AM, Tab Atkins Jr. wrote:
> > 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!
> >
> > ~TJ
> Wouldn't the large variations in implementations force content to
> actually use the values provided as-is, and not rely on specific numbers?
> That said, I think having it be a recommended area rather than the
> literal area to be painted is a good improvement.

We're working towards an implementation where we don't pre-paint anything.
My concern is that if we push out an API now that we'll have to start
lieing in the future because infinite list widgets depend on having a
pre-paint region.

> - Matt
Received on Monday, 11 April 2016 18:14:14 UTC

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