Closed
Bug 825607
Opened 12 years ago
Closed 12 years ago
offsetWidth/Height should report float values for subpixel rendering
Categories
(Core :: DOM: CSS Object Model, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: mike.sherov, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.101 Safari/537.11
Steps to reproduce:
Please look at the following fiddle: http://jsfiddle.net/7MMhB/
Actual results:
getComputedStyle returns 2.5px, and offsetWidth returns 3
Expected results:
getComputedStyle returns 2.5px, and offsetWidth returns 2.5
I know offsetWidth isn't governed by any standard, but Boris Zbarsky rightfully points out in http://bugs.jquery.com/ticket/9628 that this breaks layouts. jQuery uses offsetWidth as the basis of its dimension calculations, and in order to not succumb to rounding errors, offsetWidth/Height shouldn't round either.
Updated•12 years ago
|
Component: Untriaged → DOM: CSS Object Model
Product: Firefox → Core
Comment 1•12 years ago
|
||
Seems to be documented here: http://www.w3.org/TR/cssom-view/#extensions-to-the-htmlelement-interface
Reporter | ||
Comment 2•12 years ago
|
||
Robert, sorry about that.
Reading the spec, it doesn't *seem* like it requires an integer value. It uses "border edge" in it's definition, which also doesn't seem to imply an integer value.
Comment 3•12 years ago
|
||
From that document...
partial interface HTMLElement {
readonly attribute Element offsetParent;
readonly attribute long offsetTop;
readonly attribute long offsetLeft;
readonly attribute long offsetWidth;
readonly attribute long offsetHeight;
}
Reporter | ||
Comment 4•12 years ago
|
||
Robert, my mistake. Sorry to waste your time then.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Comment 5•12 years ago
|
||
Just to be clear... we tried changing this behavior once. It broke pages, which use the values in various ways that fail with doubles (e.g. using them as class names, which totally fails if there's a '.' in the value and the page doesn't escape it).
Just don't use offset*. Use getBoundingClientRect.
Reporter | ||
Comment 6•12 years ago
|
||
Boris, great idea!
Comment 9•12 years ago
|
||
What about it?
Comment 10•12 years ago
|
||
You advised to use getBoundingClientRect.
But when css transform is applied to element of its ancestors, returnect ClientRect is useless.
Comment 11•12 years ago
|
||
offsetWidth/Height would have the same behavior, no?
But in fact, getBoundingClientRect returns values that take transforms into account. Maybe that's what you meant by "useless"? I guess it depends on what you're trying to measure.
Comment 12•12 years ago
|
||
i am trying to get offsetWidth/offsetHeight for transformed element with scrollbars
no way to do this without changing the styles temporarily
Comment 13•12 years ago
|
||
Which width/height are you trying to get? The post-transform ones, or the pre-transform ones?
Comment 14•12 years ago
|
||
pre-transform
Comment 15•12 years ago
|
||
Then you're out of luck for now, more or less. Everyone else wanted post-transform numbers and forced us to return those...
There are some APIs being proposed that might address your use case, but they're pretty far off so far.
Comment 16•11 years ago
|
||
Note: The CSSOM View spec has been updated recently and .offset* properties now have the type "double":
http://www.w3.org/TR/cssom-view/#extensions-to-the-htmlelement-interface
Of course, if returning floats instead of integers breaks existing websites, that a valid reason not to follow the spec.
Comment 17•11 years ago
|
||
No, that would be a valid reason to change the spec to reflect reality...
Comment 18•10 years ago
|
||
Note that Chrome tried making this change too, and ran into enough compat issues that they had to back it out again (for now?):
https://code.google.com/p/chromium/issues/detail?id=378052
https://code.google.com/p/chromium/issues/detail?id=382889
https://code.google.com/p/chromium/issues/detail?id=380146
https://code.google.com/p/chromium/issues/detail?id=386500
You need to log in
before you can comment on or make changes to this bug.
Description
•