Hello Levi, The getClientBoundingRect can improve precision only for elements without any transformation applied. This demo<http://jsfiddle.net/2kEZ7/1/> shows that for a div with a transformation applied (45o rotate), getBoundingClientRect().width is different from offsetWidth. Is there any solution for getting floating-point-level precision values for this kind of elements without applying the inverse of the transformations on the bounding rectangle?
Thanks, Ion. From: Levi Weintraub [mailto:le...@google.com] Sent: Monday, June 18, 2012 8:12 PM To: Ion Rosca Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] offsetWidth/Height/Left/Top int to float Hey Ion, A few things... - We didn't actually switch to floats for Layout, but with sub-pixel layout enabled, we use integers that represent 1/60th of a pixel instead of one (similar to Gecko). - The CSSOM defines those properties to be longs http://dev.w3.org/csswg/cssom-view/#extensions-to-the-htmlelement-interface so changing this would violate the spec and potentially lead to web-compat issues. - You can get floating-point-level precision values by using getClientBoundingRect(). - IE uses a flag that switches between ints and floats. I don't advocate this option (I think it adds complexity and doesn't solve a problem that can't be solved using getClientBoundingRect) but it at least avoids web compat issues. http://msdn.microsoft.com/en-us/library/ie/hh673543(v=vs.85).aspx Hope that helps, -Levi On Mon, Jun 18, 2012 at 7:56 AM, Ion Rosca <ro...@adobe.com<mailto:ro...@adobe.com>> wrote: Hello, I have some questions regarding zooming and offsetWidth/Height/Top/Left. Currently, Element.offset* properties return imprecise values when zooming in/out. One of the bugs describing this problem would be Issue 104074: offsetWidth of element is shrinking when zooming in<http://code.google.com/p/chromium/issues/detail?id=104074> with a simple test case<http://jsfiddle.net/V4HQc/>. The product I'm working on also embeds WebKit and it would really need more precision from Element.offset*. We've done some testing by making offset*s to return floats and this approach appears to improve precision a lot. I found in archive<http://lists.webkit.org/pipermail/webkit-dev/2011-June.txt> an email from Levi Weintraub<mailto:le...@chromium.org>, sent in June 2011, saying: ... Changing rendering (and hit testing) to use floats does not necessarily mean that we need to expose floats through the dom api, however if we are to support sub-pixel layout (i.e. style=?left: 12.3px?) this would be required. Specifically we?d need to change the offsetLeft/Top/Width/Height properties to return floating point values [2]<https://bugs.webkit.org/show_bug.cgi?id=54018>. The meta bug 60318<https://bugs.webkit.org/show_bug.cgi?id=60318> (Switch away from integers ...) Levi was working on is already fixed and the inner bugs (addressing this problem) bug 54018<https://bugs.webkit.org/show_bug.cgi?id=54018> (Make offset* return doubles instead of ints) and bug 39884<https://bugs.webkit.org/show_bug.cgi?id=39884> - Full Page Zoom: rounding errors with element metrics are still opened and theirs resolution is not clear. What's your opinion on this subject? Were there some other discussions on it I couldn't find? Is there a chance for making offset properties returning floats to be accepted? What are the implications of making this change in terms of specifications? Thank you, Ion Rosca _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
