[webkit-dev] offsetWidth/Height/Left/Top int to float

[Ion Rosca]

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:leviw at google.com]
Sent: Monday, June 18, 2012 8:12 PM
To: Ion Rosca
Cc: webkit-dev at 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 <rosca at adobe.com<mailto:rosca at 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:leviw at 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 at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120618/fa96eac4/attachment.html>