Subject: Re: [blink-dev] Re: Intent to Implement and Ship: Subpixel precision for clientWidth, offsetWidth, scrollTop et al
I think we're talking just about scrollTop/scrollLeft here. We haven't enabled fractional values from offsetWidth et al. because that _does_ appear to be too web breaking. getBoundingClientRect has returned the true fractional values in Chrome for a long time though.
It is really unfortunate that this change caused some breakage. But I'm not convinced we have enough data yet to say it needs to be reverted. Fractional scroll offsets during browser zoom have been in Chrome Canary since Sept 22nd, Beta since Oct 9th and Stable since Nov 18th, and this is the first / only issue we've heard of. Compatibility is a tough tradeoff - there are no absolutes other than halting all development. We rely on upfront due diligence for what's likely to be compatible, and getting enough feedback during Beta to warn of us any really problematic changes. This change was mentioned in the Chrome 39 beta blog post
, and is covered in the intents tracking sheet
. If we had gotten this report during Beta we could have at least held off shipping to to stable for a milestone while the application in question was updated. It's unlikely we would have aborted the attempt completely based on a single example though.
To see concretely how this change improves existing code, you can use this test page
with browser zoom. Notice how on Chrome 39 the red and green boxes stay lined up (although there can still be some lag while moving - that's a separate issue we're working on). This code is doing the naive thing we see all over the web: setting a transform with the offset received from scrollTop. Prior to this change in Chrome 39 you'd see it would often be one pixel off when at 200% zoom. This example it designed to highlight the problems inherent in trying to synchronize effects with scrolling, but lots of real websites do things like this already, eg the Polymer scroll-header component
The next step for us here is to start returning fractional scroll offsets in high-dpi
cases as well as the existing browser zoom cases. I'd love any feedback on how we can mitigate further compatibility risk here. Unfortunately cases like this one where a scroll offset is passed over the network to some server which barfs on the fraction is not something we can directly search existing websites for. We could, however, do something like load the top 1-million websites and scroll their main page with and without fractions and look for any differences in JS exceptions in the two cases. Other thoughts?