Skip to main content

Bug Tracker

Side navigation

#9505 closed bug (fixed)

Opened June 03, 2011 08:58AM UTC

Closed June 16, 2012 01:28AM UTC

Last modified June 22, 2012 12:25PM UTC

animate() issue when mixing percentages and pixels in WebKit

Reported by: robert.klep@gmail.com Owned by: mikesherov
Priority: low Milestone: 1.8
Component: effects Version: 1.6.1
Keywords: Cc: paul.irish
Blocked by: Blocking:
Description

[ testcase at http://jsfiddle.net/AdrwK/1/ (watch console output) ]

When performing animation on an element which is positioned by percentage with CSS, running an animation on it using a pixel value causes problems.

fx.start is set to the percentual value (for instance '-10' when the element is positioned '-10%'), but fx.unit is px. So fx.start is interpreted as being a pixel value instead of a percentage, which causes jumps.

Issue seems to be related to WebKit (tested on Chrome 11.0.696.71 and Safari 5.0.5-6533.21.1), FF 4.0.1 and Opera 11.11 aren't affected (fx.start contains a pixel value as well).

Attachments (0)
Change History (14)

Changed June 04, 2011 06:31PM UTC by dmethvin comment:1

cc: → paul.irish
status: newopen

jQuery.fx.cur() is getting -3% back from DOM .getComputedStyle, it really should be getting pixels shouldn't it?

http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-OverrideAndComputed

http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html#computed-value

The spec is using the dreaded passive voice so it isn't totally clear who is supposed to do the translation from percent to pixels. But I think this is a Webkit bug.

Changed June 29, 2011 06:57PM UTC by timmywil comment:2

component: unfiledeffects
priority: undecidedlow

Changed November 11, 2011 11:56PM UTC by anonymous comment:3

I seem to get this issue in jQuery 1.6.4, too. It animates smoothly if only one unit is used throughout. If the element is positioned with percent and animated by pixels it appears to jump to zero before moving to the final location.

Changed May 12, 2012 10:56AM UTC by gnarf comment:4

I agree that this is a webkit issue. getComputedStyle should only return px values - right?

Changed May 12, 2012 01:58PM UTC by mikesherov comment:5

@gnarf, not really a webkit issue, more of a spec issue. getComputedStyle uses resolved value, which is defined by CSSOM, which says for top/left/right/bottom it should use computed value, which is same as cascaded value, which would be a percent in this case.

I've been petitioning both the CSSOM editor and webkit to make this change. So, although technically this is according to spec, it doesn't make sense. To make matters worse, dean Edwards awesome hack is faulty for top/left/right/bottom as we'd need to measure parent size, which is a Russian nesting doll approach and potentially super slow.

Changed May 12, 2012 02:09PM UTC by mikesherov comment:6

Just for history here: http://dev.w3.org/csswg/cssom/#resolved-values

"computed value" changed meaning between CSS spec revisions after getComputedStyle was in use. So although CSS2.1 says getComputedStyle returns "computed value", it's not the same as what CSS2.1 defines as computed value. Ugh, right? CSSOM then chose to define "resolved value" as what getComputedStyle should return, which *sort of* has the rules outlined by "resolved value", with about 20 or so edge cases and deviations in browsers. Ugh. Double ugh.

I have a whole list of bugs filed with w3c and the browsers to attack this issue, but for now, we should be saying, don't use percentages in top/left/bottom/right animations.

Changed May 24, 2012 02:40PM UTC by Fred-s comment:7

I've found a workaround:

overwrite the css value "top" and "left" with the values given by position()

before first animate().

Changed June 12, 2012 12:20PM UTC by mikesherov comment:8

milestone: 1.next1.8
owner: → mikesherov
status: openassigned

to reiterate, this is our issue to fix. getComputedStyle is one of the most divergent APIs out there, and the spec does little to help. I'll have a patch shortly.

Changed June 12, 2012 12:21PM UTC by mikesherov comment:9

#10521 is a duplicate of this ticket.

Changed June 13, 2012 01:55AM UTC by mikesherov comment:10

Fred-s, I'm going to go with your approach here. It's a fairly good workaround. Still won't get us 100% there for bottom and right, at least it'll gets us to a good spot for top and left.

Changed June 13, 2012 03:58AM UTC by mikesherov comment:11

Changed June 16, 2012 01:28AM UTC by Mike Sherov comment:12

resolution: → fixed
status: assignedclosed

Fix #9505, percentage position values in Webkit, closes gh-825.

Changeset: 0b352f6cb58a1ece3f5d1fb978cdb40bd5b0e854

Changed June 21, 2012 03:14PM UTC by mikesherov comment:13

#11932 is a duplicate of this ticket.

Changed June 22, 2012 12:25PM UTC by mikesherov comment:14

#11954 is a duplicate of this ticket.