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