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

On Mon, 09 Feb 2015 13:27:25 +0400, Simon Pieters <simonp@opera.com> wrote:

> On Mon, 09 Feb 2015 06:44:42 +0500, Rick Byers <rbyers@chromium.org>  
> wrote:
>
>> Awhile back we changed many of the CSS OM View APIs to take/return  
>> 'double'
>> values instead of 'long' to attempt to better support sub-pixel  
>> scenarios
>> like high-dpi and zooming.  We were unsure which of these were web
>> compatible.
>>
>> After chatting with Simon at the F2F, I wanted to give an update on what
>> we've learned about web compatibility from our implementation  
>> experience in
>> blink.  tl;dr is that we've successfully shipped fractional scroll  
>> offsets
>> and touch co-ordinates (and see significant benefit to doing so).  We've
>> failed to update existing measurement / positioning APIs to be  
>> fractional
>> due to web compat issues, but also don't see great benefit to doing so
>> (since we have getClientRects for precise measurement/positioning).   
>> There
>> are several other APIs we haven't attempted to upgrade to 'double' due  
>> to
>> poor benefit vs. implementation cost tradeoffs.
>
> Thanks! Unless other vendors object, I'll update the spec as you suggest.

Done. https://hg.csswg.org/drafts/rev/5278b75298ab

I also reverted width/height/availWidth/availHeight on Screen.

On Tue, 10 Feb 2015 19:57:18 +0400, 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.

OK, you can still experiment with either of these. If you change  
scrollWidth/Height and clientWidth/Height to double and it sticks, we can  
update the spec. I would also be happy to special-case scrolling to the  
end if that improves Web pages.

On Wed, 11 Feb 2015 10:33:56 +0400, Rick Byers <rbyers@chromium.org> wrote:

> 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).

I don't expect most authors to do either of these things, really. It seems  
more useful to make the necessary changes in the browser to improve the  
user experience while remaining compatible enough with Web pages'  
assumptions.

On Wed, 11 Feb 2015 22:50:20 +0400, Emil A Eklund <eae@chromium.org> wrote:

> Correct. Having scrollTop/Left have subpixel precision without having
> the same for scrollWidth/Height seems really inconsistent and
> unfortunate though. I really do think that we need to have some way to
> get the precise scrollable size, be that though changing
> scorllWidth/Height or by adding a new getScrollableSize/Rect API.

I haven't added a new API for this yet.

-- 
Simon Pieters
Opera Software

Received on Thursday, 12 February 2015 10:23:45 UTC