offsetLeft is defined in CSSOM.

This isn't the same offetLeft that CSSOM defines. bokan@ will hopefully know which component this lives in.

From comment #2, it seems like Blink>CSS is the wrong component? I've removed the Blink>CSS component for now, but feel to add it back if the bug indeed belongs in Blink>CSS.

https://www.youtube.com/watch?v=z9TXSciTxkc - here's the sort of snapping this issue causes.

This surprised me (since it's a major bummer for many of the use cases of the API) until I realized it's a longstanding, more general issue: issue 456622 and issue 414283.

Basically, Blink isn't really aware of non-integer scroll offsets (it does a bit of work for browser zoom but that's it); that's all handled inside the compositor and hidden from Blink. This isn't really an easy fix.

The good news is that this is on our radar and hope to have this fixed in the near-medium term.

Rob: we've recently had fixing the issues above as a priority, do you have a sense if any progress has been made? I think this is more important for the visual viewport since it necessarily deals with zoomed in fractional values so aligning things in integers results in ugly results. We could special case the offsets for the visual viewport but that seems hacky when we want to do it for all scrollers at some point. IMO, perhaps we should put extra emphasis on it in Q4 - perhaps chaopeng@ or sahel@ could invest some time here if it's a question of resources.

 Issue 636385  has been merged into this issue.

 Issue 636385  was about scrollLeft/scrollTop, I think this bug should apply for those properties as well?