W3C home > Mailing lists > Public > www-style@w3.org > February 2015

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

From: Rick Byers <rbyers@chromium.org>
Date: Wed, 11 Feb 2015 17:33:56 +1100
Message-ID: <CAFUtAY8fbOvGT3epbYLUU8+__Fz=P6RQaEj-sP3kcuiwwUNJbQ@mail.gmail.com>
To: "eae@chromium.org" <eae@chromium.org>
Cc: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>, Yufeng Shen <miletus@chromium.org>, David Bokan <bokan@chromium.org>, Jacob Rossi <Jacob.Rossi@microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>
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
Received on Wednesday, 11 February 2015 06:34:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC