#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
Component: | core → effects |
---|---|
Keywords: | problem animate zindex added |
Owner: | set to gdripoll |
Priority: | major → low |
Status: | new → pending |
comment:2 Changed 13 years ago by
Status: | pending → closed |
---|
Automatically closed due to 14 days of inactivity.
comment:15 Changed 13 years ago by
Milestone: | 1.4 → 1.next |
---|---|
Status: | closed → reopened |
Version: | 1.3.2 → 1.5 |
comment:16 Changed 13 years ago by
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
Owner: | changed from gdripoll to jitter |
---|---|
Status: | reopened → assigned |
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:
- It's not an integer like the value for z-index should be
- 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
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Don't add "px" to unit-less properties when animating them. Fixes #4966.
Changeset: c5edf982d59977c506fececd504a3dbfd1a398dc
comment:8 Changed 13 years ago by
Milestone: | 1.next → 1.5.1 |
---|
comment:9 Changed 12 years ago by
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().
Please submit a test case that reproduces this issue so that we can investigate it more thoroughly.