Re: RFC: Rendering Independent Scroll Offsets

Thanks for the feedback.


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

The display of the content would be unchanged, so pixel snapping during
paint and compositing
will continue as today. This would strictly be the values as reported by
Element.scrollTop and some
non-display related ways they're used (e.g. getBoundingClientRect uses the
more precise
unsnapped value)


> Having the scroll offsets be unsnapped might lead to the usual floating
> point comparison issues,
>

I think it's already an issue. Various odd floating point values are
already possible, they just
depend on the device and screen density. e.g. the Nexus 5X example. The
advantage of having it
apply everywhere means the issues would be consistent across devices and
more likely to be
noticed/fixed.

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.


It's true that the scroll offset as stored in scrollTop might change even
though there's no repaint or
display change and two scroll offsets can be different even though they
paint at the same location.
Off hand, I'm not sure if that's a problem yet.

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 think a major difference is the ubiquity of zooming on the web. Both
Ctrl+/- and pinch-zoom on
web mean that sub-CSS-pixel scrolls are fairly common. I wonder also if Mac
and iOS don't see
similar issues since the scale factors are generally whole numbers? Android
has some exotic scaling
factors that cause surprises for developers.

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.
>

Blink had the same issues. I believe they were solved keeping everything in
ints but as physical pixels
and then transforming values to CSS pixels when reported to web APIs.

On Thu, Jan 30, 2020 at 2:28 PM Simon Fraser <smfr@me.com> wrote:

> 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>. I requested
> and received a brief TAG review
> <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
>