Bug 54018

Summary: Make offset* return doubles instead of ints
Product: WebKit Reporter: Erik Arvidsson <arv>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: annevk, eae, leviw, playmobil, rosca, sam, tonikitoo
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 60318    
Bug Blocks:    

Description Erik Arvidsson 2011-02-08 10:00:37 PST
When the user zooms out on the page it is very likely that the offsetTop/Left/Width/Height are non integers. We currently floor these which leads to UI bugs in JS code.
Comment 1 Sam Weinig 2011-02-08 10:11:13 PST
Which offsets are you referring to?  Things like Element.offsetLeft? Can we do that without breaking web compat? It looks like CSSOM-view defines them as returning longs (http://dev.w3.org/csswg/cssom-view/#extensions-to-the-htmlelement-interface). Perhaps we should bring this up in the WG.
Comment 2 Erik Arvidsson 2011-02-08 10:56:27 PST
(In reply to comment #1)
> Which offsets are you referring to?  Things like Element.offsetLeft? 

offsetLeft
offsetTop
offsetWidth
offsetHeight

but eventually I would like us to fix all cases where we use a non integer internally but expose it as integer to scripting


>Can we do that without breaking web compat?

I'm not sure. Gecko returns non ints for computed style which makes me believe it would be OK to change this.

> It looks like CSSOM-view defines them as returning longs (http://dev.w3.org/csswg/cssom-view/#extensions-to-the-htmlelement-interface). Perhaps we should bring this up in the WG.

Yes
Comment 3 Levi Weintraub 2011-06-13 15:35:53 PDT
> > It looks like CSSOM-view defines them as returning longs (http://dev.w3.org/csswg/cssom-view/#extensions-to-the-htmlelement-interface). Perhaps we should bring this up in the WG.
> 
> Yes

I'm sorry I haven't kept close tabs on the discussions, but if this came up, any chance I could get a link to the discussion?
Comment 4 Emil A Eklund 2011-06-23 17:05:56 PDT
None of the major browsers returns floats for the offset properties (yet!), they do return floats for computed style and getClientBoundingRect though
Comment 5 Ion Rosca 2012-06-18 00:26:14 PDT
All rendering has been changed to use floats, but offset*s from dom api still return rounded values. These values may vary with 1px when zooming because of rounding, and I couldn't find out how to get more precise results from JS.
Is there a plan for exposing more precise offset* values through dom api (making offset* return floats instead of ints, exposing other properties/methods)?
Comment 6 Emil A Eklund 2012-06-19 04:06:18 PDT
(In reply to comment #5)
> Is there a plan for exposing more precise offset* values through dom api (making offset* return floats instead of ints, exposing other properties/methods)?

Not at this time. More precise metrics is available through getBoundingClientRect.
Comment 7 Ion Rosca 2012-06-19 04:56:44 PDT
The bounding rectangle changes when applying some transformations on an element (http://jsfiddle.net/2kEZ7/1/) and cannot be used anymore replacing offset properties. What would be the right solution in this case in your opinion?
Comment 8 Emil A Eklund 2012-06-19 05:03:27 PDT
(In reply to comment #7)
> The bounding rectangle changes when applying some transformations on an element (http://jsfiddle.net/2kEZ7/1/) and cannot be used anymore replacing offset properties. What would be the right solution in this case in your opinion?

It really depends on what you are trying to do. We cannot change the offset properties to return higher precision numbers at this time without violating the specification and causing webcompat issues as the behavior would be different from that in other browsers.
Comment 9 Ion Rosca 2012-06-19 07:04:44 PDT
In my case WebKit is embedded in a tool used to create animated web content using HTML5, CSS3 an JS. This tool uses lots of transformations on elements to create irregular shapes. Each element has a quadrilateral handler that suits best the transformed element. Application uses offsetW/H to draw handlers. When zooming in/out, because of offset* lack of precision, handlers overlap, are drown inside or outside the elements.
I agree we should follow specificationa and care about browser compatibility, but there are cases where we need precise metrics and we don't have them neither using offsetW/H nor using getBoundingClientRect.
IE has solved this problem by using a flag that switches between ints and floats for offset properties. This solution appears to violate the spec. We might propose an extended set of offset properties without touching the old ones, or any other solution that follows the spec and exposes through dom api more precise information from WebKit.
Comment 10 Erik Arvidsson 2012-06-19 10:10:15 PDT
We should just change the spec.

The real question is if this will cause a lot of real world bugs. Maybe we can get away with returning ints in quirks mode? Only enabling this in a dev channel would allow us to get feedback.
Comment 11 Levi Weintraub 2012-06-19 17:08:28 PDT
(In reply to comment #10)
> We should just change the spec.
> 
> The real question is if this will cause a lot of real world bugs. Maybe we can get away with returning ints in quirks mode? Only enabling this in a dev channel would allow us to get feedback.

This seems like a reasonable way forward to me.
Comment 12 Anne van Kesteren 2023-12-11 06:57:51 PST
While this might still be the right idea, this should really start with a standardization discussion and compat analysis and then we can consider implementing.