RFC: Rendering Independent Scroll Offsets

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.

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

Thanks,
David