Re: RFC: Rendering Independent Scroll Offsets

> On Jan 27, 2020, at 6:35 AM, David Bokan <bokan@google.com> wrote:
> 
> Hello www-style,
> 
> I wanted to give a heads up and request any feedback on a change I'd like
> to make to how scroll offsets are reported in Blink. The full details are
> in this explainer
> <https://github.com/bokand/RenderingIndependentScrollOffsets <https://github.com/bokand/RenderingIndependentScrollOffsets>>. I requested
> and received a brief TAG review
> <https://github.com/w3ctag/design-reviews/issues/409 <https://github.com/w3ctag/design-reviews/issues/409>> and was pointed this
> way.
> 
> To summarize:
> 
> Scroll offsets as reported by `window.scrollY` or `Element.scrollTop` are
> double-type but rendering-engines limit the range of these values, often to
> the nearest physical pixel. That is, if physical pixel == CSS pixel,
> setting `Element.scrollTop = 1.5` will result in `Element.scrollTop == 1`.
> The way in which physical-pixel boundaries are computed aren't consistent,
> even within a single engine e.g. pinch zoom doesn't change this granularity
> even though users can scroll and see it in finer increments.
> 
> This is a foot gun for developers as code that works on one device may not
> work on another. Take the Nexus 5X with its devicePixelRatio of 2.625. It
> can be surprising to authors that `scrollTo(0, ,20)' results in
> `window.scrollY == ~19.8`. 20 CSS pixels do not land on a physical pixel
> boundary.
> 
> More examples and motivation are in the explainer.
> 
> I'd like to change this so that scroller offsets are kept and reported in
> the full range of floating point values and make pixel snapping an artifact
> of the rendering process. I believe this is a better abstraction, more
> consistent with other API's like getBoundingClientRect, and more intuitive
> for web authors to reason about.

You'd pixel-snap both for painted scrolled content, and for composited scrolled content, right?

Having the scroll offsets be unsnapped might lead to the usual floating point comparison issues,
especially with scroll snapping, or JS trying to determine whether the scroll offset is the same as
some previous offset. This could also be a problem in implementations.

Also note that on macOS and iOS at least, the native scrollers always use pixel-snapped values,
meaning that on these platforms we'd continue to snap the actual scroller offsets. I think I'd prefer
that the actual scroll offsets are snapped.

> 
> I'm interested if anyone has any feedback or interest in what parts of this
> behavior should be specified.

I think this is a change in the right direction. WebKit's scrolling implementation currently is int-based,
which results in various fixed-position jitters on 2x and 3x displays.

Simon