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

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

From: Emil A Eklund <eae@chromium.org>
Date: Wed, 11 Feb 2015 02:57:18 +1100
Message-ID: <CADu_oUCBNr4HX9yTLLUf7RBz_LA_hyEAew3ivcKQiHm6YKAcyw@mail.gmail.com>
To: Rick Byers <rbyers@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>
> 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.
Received on Wednesday, 11 February 2015 13:16:12 UTC

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