ryanwheale

I just wanted to say I was having the same issue and found a solution. Please note that I am building a large ajax-driven app which loads all resources with an AMD loader. I am not sure if this will solve anybody else's problems, but here's ahhh solution. In my situation, TweenMax was getting a null zIndex for an item which definitely had a z-index specified in my styles. However, I am using LESS during development, and I am using the in-browser LESS engine which parses the LESS files in the browser and writes the compiled CSS to a style tag. I verified that the LESS engine was done compiling before triggering TweenMax, however Safari still returned a null zIndex. It turns out that Safari needed an extra CPU cycle so the browser could finish calculating the dynamically injected styles. A zero timeout worked nicely. The following is my modified p._onInitTween method (near line 3700 of TweenMax.js): if (_reqSafariFix) if (style.zIndex === "") { setTimeout(function() { _cs = _getComputedStyle(target, ""); v = _getStyle(target, "zIndex", _cs); if (v === "auto" || v === "") { //corrects a bug in [non-Android] Safari that prevents it from repainting elements in their new positions if they don't have a zIndex set. We also can't just apply this inside _parseTransform() because anything that's moved in any way (like using "left" or "top" instead of transforms like "x" and "y") can be affected, so it is best to ensure that anything that's tweening has a z-index. Setting "WebkitPerspective" to a non-zero value worked too except that on iOS Safari things would flicker randomly. Plus zIndex is less memory-intensive. style.zIndex = 0; } }, 0); }