jQuery doesn't take into account CSS scale transform when getting height/width of element

[paulshapiro]

Seem to have run into this issue in a roundabout way. I was using a plugin called jsPlumb which needs to get the outerWidth and outerHeight of an element. Problem is that my element needs to have a CSS scale transform applied to it. It seems like jQuery uses the unscaled value for outerHeight and outerWidth.

I got in touch with the jsPlumb developer and he said it looks like a jQuery issue, so I decided to report it here.

Here's a Fiddle that demonstrates my problem,

​http://jsfiddle.net/hW5qY/19/

And here is the jsPlumb Google Code Issue,

​http://code.google.com/p/jsplumb/issues/detail?id=160

Thanks for looking into this! Any info would be a great help.

Paul

[Timmy Willison]

Thanks for taking the time to contribute to the jQuery project! Please provide a reduced test case that does not contain the plugin.

Additionally, be sure to test against the jQuery Edge(git) version to ensure the issue still exists.

related: #8362

[paulshapiro]

Hi timmywil,

Alrighty, I stripped out the line with the call to jsPlumb and replaced the jsPlumb ready with a document ready.

​http://jsfiddle.net/hW5qY/21/

Unfortunately I don't have enough time this weekend to checkout and test the latest dev version of jQuery. Maybe I can get to it within a week but not sure as we're launching our startup this coming week. Depends on the problems we encounter.

I did see the related issue and have actually encountered a problem with jQuery UI + CSS scale resulting in the wrong offsets but managed to work around that one a few weeks ago by making sure it scaled from the upper left corner (0%,0%) instead of the center (50%,50%)

Thanks for your time.

[Timmy Willison]

To me, it is debatable whether the computed results for width/height should be affected by transforms. The amount of space the browsers use to draw the elements is the real width and height and webkit/firefox report the unaffected width/height in their computed values, which we are relaying in css. To check for scale is probably too expensive in time, size, and performance.

Given that the browsers do not see the need to update computed values during transforms, I'm not sure we should either.

[paulshapiro]

If in your view it really is debatable, then I hope it's alright if I'm honest. To be frank, that seems like kind of a cop-out to me. This computation has to be handled somehow, and if not by jQuery then it'll have to be done by the user.

There are many things that the browser doesn't do that jQuery does, so I'm not sure that justification (that the browser doesn't handle it) can really stand on its own.

What do you mean that the amount of space browsers use to draw the element is the real width and height. That is, what do you mean by the real width and height?

If performance is the issue then I'm sure there are ways to make it faster. Even if not, for example, an option could be set somewhere (like passed into outerWidth/outerHeight) to determine whether or not to check for scale. That may not even the optimal possible solution.

Would have to know what you mean by real width and height before I know if I've misunderstood you or not.

Thanks! Paul

[anonymous]

It would be good to get some replies to Paul's questions.

[dmethvin]

Applies to basically all dimensions, per #8362. See the code referenced in that ticket. It's huge.

[dmethvin]

Duplicate of #8362.

[jovan@…]

The incorrect width and height of a div ( i.e. a droppable ) affects a draggable.

As a droppable div is triggered by it's width and height, this becomes an issue due to the fact that if the droppable div is ( ie. smaller ) after a transform scale it is triggered by a draggable before the draggable is near the edges of the droppable.

[dan.kellett@…]

It would be nice if jQuery exposed the javascript API "getBoundingClientRect()" somehow. I think this would solve the reporters needs.