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

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.

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

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?

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.

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

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.

Rick