Bug Tracker

Opened 14 years ago

Closed 13 years ago

Last modified 12 years ago

#4966 closed bug (fixed)

Problem with animate and zIndex

Reported by: gdripoll Owned by: jitter
Priority: low Milestone: 1.5.1
Component: effects Version: 1.5
Keywords: problem animate zindex Cc:
Blocked by: Blocking:

Description

There's a problem width animate and zIndex in IE8 (didn't check previous versions yet, but Firefox and Chrome doesn't seem to have the problem).

I followed the problem upto line 4166 in Developer version:

fx.elem.style[ fx.prop ] = fx.now + fx.unit;

Apparently, it tries to append 'px' in the case of zIndex, which is erroneous. I temporaly patched it to:

fx.elem.style[ fx.prop ] = fx.now + ((fx.prop!="zIndex")?fx.unit:"");

and it works.

Shure not the best solution.

Change History (9)

comment:1 Changed 13 years ago by addyosmani

Component: coreeffects
Keywords: problem animate zindex added
Owner: set to gdripoll
Priority: majorlow
Status: newpending

Please submit a test case that reproduces this issue so that we can investigate it more thoroughly.

comment:2 Changed 13 years ago by trac-o-bot

Status: pendingclosed

Automatically closed due to 14 days of inactivity.

comment:14 Changed 13 years ago by jitter

#8188 is a duplicate of this ticket.

comment:15 Changed 13 years ago by jitter

Milestone: 1.41.next
Status: closedreopened
Version: 1.3.21.5

comment:16 Changed 13 years ago by KuraFire

Just as a note: only IE browsers have a problem with "z-index: 0px" (or any value other than 0, as long as it has the "px" suffix). Other browsers ignore the unit and reduce it to an integer. Whether that’s to spec or not is debatable, but it doesn’t make sense for a library to explicitly specify it. :-)

comment:17 Changed 13 years ago by jitter

Owner: changed from gdripoll to jitter
Status: reopenedassigned

test case

This actually fails in all browsers for me. Reason is that it ends up settings things like 8.816275116495891px which is wrong in two ways:

  1. It's not an integer like the value for z-index should be
  2. the unit "px" is appended.

Internally we already have the cssNumber object which holds properties that have no unit.

There probably are several valid approaches to this that come to mind (use the cssNumber object somehow, change the usage of the rfxnum results, include special fx.step functions for all the numeric-no-unit properties?)

Which one is the most appropriate one remains to be evaluated.

I imagine a possible fix could be to change this line in animate

unit = parts[3] || "px"

to something like this

unit = parts[3] || jQuery.cssNumber[ name ] ? "" : "px"

Replying to KuraFire:

Just as a note: only IE browsers have a problem with "z-index: 0px" (or any value other than 0, as long as it has the "px" suffix). Other browsers ignore the unit and reduce it to an integer. Whether that’s to spec or not is debatable, but it doesn’t make sense for a library to explicitly specify it. :-)

I can't seem to reproduce that "reduce to integer" behavior, but I saw that you included some Math.round/Math.floor code in your plugin.

Btw. my test case includes a - commented out - workaround that should work until this is fixed in jQuery core.

comment:7 Changed 13 years ago by Anton M

Resolution: fixed
Status: assignedclosed

Don't add "px" to unit-less properties when animating them. Fixes #4966.

Changeset: c5edf982d59977c506fececd504a3dbfd1a398dc

comment:8 Changed 13 years ago by jitter

Milestone: 1.next1.5.1

comment:9 Changed 12 years ago by zach@…

While this fixes the z-index bug, it also breaks old code written based on what the animate() documentation says: "Property values are treated as a number of pixels unless otherwise specified."

Instead of not adding 'px' at all, is there a way to instead have a list of specific properties that won't get 'px' appended? It's a minor pain to have to manually concatenate 'px' to every number used with the animate().

Note: See TracTickets for help on using tickets.