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

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?

> 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

Received on Monday, 9 February 2015 03:28:00 UTC