Re: [cssom-view] Which APIs should be 'double' vs. 'long'

On Wed, Feb 11, 2015 at 2:57 AM, Emil A Eklund <eae@chromium.org> wrote:

> > I believe there were, but I could be wrong and can't find details in the
> > bugs.  eae@ do you have reason to expect serious compat issues with
> making
> > scrollWidth and scrollHeight doubles?  I don't think we've ever tried to
> > change those without also changing offsetWidth/offsetHeight, so I'd be
> > willing to take a crack at that if we don't have concrete data so say
> why we
> > can't.
>
> Comparing scrollWidth/scrollHeight with clientWidth/clientHeight using
> the equality operator is a quite common pattern to check whether an
> element is scrollable or not. Any change that breaks that is likely to
> have compatibility issues. If we change clientWidth/Height to subpixel
> precision I'd argue we also need to change clientWidth/Height.
>
> As we discussed in person another, more conservative, option would be
> to keep scrollWidth/Height as integers and instead special case
> scrolling to the end.
>
> I.e., today setting scrollLeft = scrollWidth - clientWidth does not
> guarantee that it scrolls to the end as scrollWidth and clientWidth
> are both rounded.
>

Thanks Emil.

It doesn't feel to me (absent use cases) that this particular scenario is
important enough to risk web compat pain for, or to justify some sort of
crazy language in the spec (for special casing scroll-to-end).  Client code
can already attempt to scroll to 'scrollHeight - clientHeight + 1' (or just
a large constant) to reliably get to the end of a scroller, right?  Maybe
that's good enough.  Or maybe we should just bite the bullet and add
subpixel-aware versions of the scrollHeight/Width APIs (like
getBoundingClientRect).