Summary: | Make offset* return doubles instead of ints | ||
---|---|---|---|
Product: | WebKit | Reporter: | Erik Arvidsson <arv> |
Component: | DOM | Assignee: | 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
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. (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 > > 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?
None of the major browsers returns floats for the offset properties (yet!), they do return floats for computed style and getClientBoundingRect though 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)? (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. 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? (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. 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. 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. (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. 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. |