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

On Mon, Dec 21, 2015 at 3:33 AM, Simon Pieters <simonp@opera.com> wrote:

> On Fri, 18 Dec 2015 18:55:20 +0100, Trav Stone <travtrilogi@gmail.com>
> wrote:
>
> Hi Simon,
>>
>> Many thanks! Had no idea Range existed, but it does indeed return the
>> value
>> I need. I'd still argue that your proposed API is a bit easier to use than
>> Range, but perhaps I'm in the minority with that viewpoint.
>>
>> At any rate, I really appreciate your response- very helpful!
>>
>
> The proposed API is not at all instead of Range. It's instead of
> Element#scrollWidth etc.
>
>
> On Fri, 18 Dec 2015 19:08:41 +0100, Rick Byers <rbyers@chromium.org>
> wrote:
>
> I had thought an API like getScrollRect wasn't necessary because
>> getBoundingClientRect + fractional scrollTop/scrollLeft covered all the
>> scenarios.  But if there are scenarios that need fractional
>> scrollHeight/scrollWidth (or maybe even if it's demonstrably easier to use
>> getScrollRect), then I'd certainly support your getScrollRect proposal.
>>
>
> Consider Trav's case, but there is a scrollbar visible. Then
> getBoundingClientRect doesn't return the width you want. You want the width
> excluding the scrollbar, if there is one.
>
> Or if there's a border, then getBoundingClientRect includes the border.
> But getBoxQuads() lets you select the content box... An alternative would
> be to extend getBoxQuads() with a way to get the "content minus scrollbars"
> box.
>
>     elm.getBoxQuads({box: 'scroll'})[0].getBounds().width
>
> It's more wordy than elm.scrollWidth (and elm.getScrollRect().width),
> although you can support transformed boxes.


Makes sense, thanks.  Your proposal seems like the best (simplest) option
to me.  If another vendor was interested in shipping this, I suspect we'd
probably be interested in blink as well (though we'd need to run it by some
more to confirm folks of course).


>
> --
> Simon Pieters
> Opera Software
>