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

On Mon, Feb 9, 2015 at 8:27 PM, 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.
>
>  Details:
>>
>> 1) Scroll offsets
>> Window: scrollX pageXOffset scrollY pageYOffset scrollTo scrollBy
>> Element: scroll scrollTo scrollBy scrollTop scrollLeft
>> ScrollToOptions: left top
>> We have been shipping these as fractional APIs for some time (
>> http://crbug.com/373731) and have had only minor web compat issues which
>> we've been able to cope with.  We've had implementation issues delaying
>> exposing the fractional values in all cases (http://crbug.com/414283),
>> but
>> I expect those to all be resolved soon.  I'm relatively confident that
>> we've gotten enough exposure from the scenarios where we already return
>> fractions (eg. browser zoom) that any additional web compat issues will be
>> manageable.  We've also got examples where we believe changing scrollTop
>> to
>> double will transparently result in a smoother user experience (eg. for
>> scroll linked effects).
>>
>
> OK, I agree it seems good to have these as double.
>
>  2) Element measurements / positioning
>> Element: scrollWidth scrollHeight clientTop clientLeft clientWidth
>> clientHeight
>> HTMLElement: offsetTop offsetLeft offsetWidth offsetHeight
>> HTMLImageElement: x y
>> We attempted to change most of these to double (http://crbug.com/360889),
>> but hit a variety of issues on many different websites.  For example, we
>> saw one case where the application was using co-ordinates as an index into
>> an array which was populated with integer keys.  It's also not clear to me
>> that there's a ton of benefit here when we have great precise measurement
>> APIs like getClientRects.  At the moment we do not plan to try to ship
>> fractional versions of these APIs.  IIRC, WebKit had a similar experience.
>> IE only exposes fractional values here
>> when document.msCSSOMElementFloatMetrics is set true.  If we want to
>> pursue
>> making these APIs fractional, I think we should do so only by adding new
>> APIs (eg. 'scrollHeightDouble').  Perhaps getBoundingClientRect is
>> adequate
>> and we should just leave these alone as integers?
>>
>
> Yeah. It is slightly weird that scrollWidth is long but scrollLeft is
> double, though. Were there issues with scrollWidth/scrollHeight in
> particular?


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.

 3) Hit-testing APIs
>> Document: elementFromPoint elementsFromPoint caretPositionFromPoint
>> We haven't attempted to update these, but I think we should.  It should be
>> easy for us to implement (for the simple cases anyway - some special cases
>> may still involve sub-pixel inaccuracies internally) and low risk from a
>> web compat perspective.  http://crbug.com/387644.
>>
>
> Agreed.
>
>  4) Input co-ordinates
>> MouseEvent: screenX screenY pageX pageY clientX clientY x y offsetX
>> offsetY
>> We successfully shipped fractional TouchEvent co-ordinates (
>> http://crbug.com/379150) and saw benefit from doing so.  I suspect we can
>> successfully ship fractional MouseEvent co-ordinates as well (especially
>> since IE has done so since IE 10), but it has not been a priority for my
>> team.  I support leaving these as 'double' and hopefully we'll get around
>> to shipping that some day (http://crbug.com/456625).
>>
>
> OK.
>
>  5) Viewport positioning/sizing
>> Window: moveTo moveBy resizeTo resizeBy innerWidth innerHeight screenX
>> screenY outerWidth outerHeight
>> We have not attempted to turn these into double.  I suspect there's
>> non-trivial web compat risk (as for element sizing/measurement).  There's
>> also non-trivial work required for us to implement this in blink.  At the
>> same time I'm not sure there's much benefit.  Last I checked, many OSes
>> didn't support positioning/sizing windows at sub-DIP precision.  Unless
>> other vendors feel differently, I think we should just change these back
>> to
>> 'long' in the spec.
>>
>
> That seems reasonable. If the situation changes in the future and OSes
> support sub-pixel window positioning and there is demand for this, we can
> change it again and check if it is compatible, but currently it seems it
> would be meaningless for browsers to change from long to double for these.
> Also, window.open()'s features argument only supports integers currently.


>
> --
> Simon Pieters
> Opera Software
>