I think this looks pretty reasonable. It improves consistency of these APIs with a bunch of other layout-related APIs that report unrounded positions but where the implementation pixel-snaps things later (e.g., getBoundingClientRect).

There is one loss of information in that prior to this change, what it sounds like Chrome and Firefox were doing reported the way the implementation did pixel-snapping -- something that I suppose could potentially be useful.

But assuming that implementations are consistent about doing pixel-snapping of scroll positions the same way they do pixel-snapping of edges (which I certainly hope is the case -- and which I'd hope would be specified in the changes proposed here), it seems like that's not a huge issue, especially since there isn't really API surface for getting the way anything else pixel-snaps.

In any case, @alice and I just discussed this in a breakout, and we're fine with closing this issue.

It seems worth bringing a proposal to CSS -- there may be some folks there who have additional feedback. And I think the group should be capable of reviewing changes to cssom-view even if the spec doesn't have an active editor.

Thanks for asking the TAG for review.

Thanks for the review! I'll follow up in www-style.

There is one loss of information in that prior to this change, what it sounds like Chrome and Firefox were doing reported the way the implementation did pixel-snapping -- something that I suppose could potentially be useful.

Yes and no; it's rather inconsistent. For example, Firefox will report the pixel snapping for user scrolls (e.g. trackpad scrolling on a 2X high-DPI monitor will show 0.5 increments in window.scrollY) but not for programmatic scrolls (on the same high-DPI monitor, window.scrollTo(0, 10.5) will report 10 for window.scrollY). Another case: Chrome doesn't report snapping information when pinch-zoom is involved.

But assuming that implementations are consistent about doing pixel-snapping of scroll positions the same way they do pixel-snapping of edges

One interesting detail I learned recently is that Chrome does subpixel blending for layout but not for scroll (when fractional offsets are turned on). Here's an example. That is, if layout falls inbetween a physical pixel, the painted result will actually blend the boundary pixels. In the example, we paint purple rather than red or blue for the "boundary" pixel.

I'm not sure it'd be good to specify exactly how snapping should work. e.g. for scrolling, we probably don't want to continually apply the subpixel blending since it causes us to do a lot of extra work and defeats the "off-main-thread" compositing/async scroll optimizations.

I agree though we want to make it possible to align layout positioning with scroll offsets for per-pixel accuracy so, for example, one shouldn't snap using floor() and the other round(). I'll have to do a bit more research here and I'll follow up with the CSS group to figure out how much of this should be specified vs. UA defined.

Thanks again!