825607 - offsetWidth/Height should report float values for subpixel rendering

Status: RESOLVED INVALID

(Core :: DOM: CSS Object Model, defect)

Description

[Mike Sherov]

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.

Comment 1

[Robert Longson [:longsonr]]

Seems to be documented here: http://www.w3.org/TR/cssom-view/#extensions-to-the-htmlelement-interface

Comment 2

[Mike Sherov]

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

[Robert Longson [:longsonr]]

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;
}

Comment 4

[Mike Sherov]

Robert, my mistake. Sorry to waste your time then.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Mike Sherov]

Boris, great idea!

Comment 8

[4esn0k]

Oh... what if the element was transformed with CSS ?

Comment 9

[Boris Zbarsky [:bzbarsky]]

What about it?

Comment 10

[4esn0k]

You advised to use getBoundingClientRect.
But when css transform is applied to element of its ancestors, returnect ClientRect is useless.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

[4esn0k]

i am trying to get offsetWidth/offsetHeight for transformed element with scrollbars

no way to do this without changing the styles temporarily

Comment 13

[Boris Zbarsky [:bzbarsky]]

Which width/height are you trying to get?  The post-transform ones, or the pre-transform ones?

Comment 14

[4esn0k]

pre-transform

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

[Šime Vidas]

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

[Boris Zbarsky [:bzbarsky]]

No, that would be a valid reason to change the spec to reflect reality...

Comment 18

[Boris Zbarsky [:bzbarsky]]

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