Skip to main content

Bug Tracker

Side navigation

#11114 closed bug (duplicate)

Opened December 29, 2011 09:58PM UTC

Closed April 18, 2012 12:12PM UTC

Last modified March 06, 2014 12:46AM UTC

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

Reported by: paulshapiro Owned by: paulshapiro
Priority: low Milestone: None
Component: dimensions Version: 1.7.1
Keywords: Cc:
Blocked by: Blocking:

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,

And here is the jsPlumb Google Code Issue,

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


Attachments (0)
Change History (10)

Changed December 30, 2011 04:05PM UTC by timmywil comment:1

component: unfileddimensions
owner: → paulshapiro
priority: undecidedlow
status: newpending

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

Changed December 30, 2011 06:31PM UTC by paulshapiro comment:2

status: pendingnew

Hi timmywil,

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

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.

Changed December 30, 2011 10:45PM UTC by timmywil comment:3

resolution: → wontfix
status: newclosed

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.

Changed December 30, 2011 10:56PM UTC by paulshapiro comment:4

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.



Changed April 18, 2012 06:50AM UTC by anonymous comment:5

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

Changed April 18, 2012 12:12PM UTC by dmethvin comment:6

resolution: wontfix
status: closedreopened

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

Changed April 18, 2012 12:12PM UTC by dmethvin comment:7

resolution: → duplicate
status: reopenedclosed

Changed April 18, 2012 12:12PM UTC by dmethvin comment:8

Duplicate of #8362.

Changed May 07, 2013 10:35AM UTC by comment:9

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.

Changed March 06, 2014 12:46AM UTC by comment:10

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