Jump to content

Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Newbie

About BaskingShark

  • Rank

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

803 profile views
  1. Since I'm importing the NPM package it's hard for me to switch over to test that beta, but looks to me like making sure "e !== _docElement" should do it. Thanks for patching that up!
  2. Thanks for the info! That's good detail to know and I'll keep it in mind as I'm building animations. Should I look for a patch in a future version or is this too much of an edge case and I should modify my existing timelines that touch the html element?
  3. Hi Jack, Yes, this is only a problem when changing a class on the html element as part of a timeline. I admit it's a rare case and I can go through my code and work around it now that I've identified the issue, but it is an unintentional breaking change from 2.0.x to 2.1.x and after a good part of a day trying to track down what was going on it might be something you either want to patch or that other people could encounter and need to know to avoid. I'm surprised to hear you don't recommend changing classes in timelines since I hadn't read anything about it being a per
  4. The update to 2.1.x started throwing errors in several spots in my project so I rolled back until I could get a chance to debug what was different. I finally worked out what the problem is: you can no longer change a class on the HTML element as part of a timeline. This seems to be a change in CSSPlugin.js that pushes every call to the set() function in TimelineLite through the "_getMatrix" function. That function performs a trick when the element isn't visible by appending the element to the DOM. Unfortunately, if the target is the HTML element that causes a "DOMException: Failed
  5. While i absolutely agree this is sloppy syntax — the result of weeks of editing and re-edting a massive web app — it’s also a structure that was fully supported until this point release. And one that works with the aim of autoCSS to provide a shortcut for frequently animated css properties. It seems to me that either the documentation needs to be updated to explicitly warn against mixing css and autoCSS properties, or the code needs to continue to support a combination within a single statement as it has until 1.19.1. I just figure that if this situation showed up for me and broke a fully
  6. OK, I finally tracked down the bug and modified my original Codepen to demo it. The issue is with the updated _addPropTween function on TweenMax's line 6984. It's an obscure one for sure: When you set opacity on an element and also set a css class, like var tl = new TimelineMax().set(obj, {opacity: 0, css: {className: '+=active'}}); the new _addPropTween function mistakenly adds opacity to that DOM element's properties. Then if that element is tweened later on and opacity is one of the css properties being manipulated, TweenMax's line 6866 if (!_reservedProps[p] && (!(p in targ
  7. I've seen the same behavior on macOS 10.12.3 with both Chrome 56.0.2924.87 and Firefox 51.0.1. Thanks!
  8. Just ran a test and will-change doesn't make a difference in the opacity bug -- it still skips that portion of the CSSPlugin code -- but autoAlpha works in either case. I'll stick with that. Still, I'm removing that will-change and a few others; thanks! The way that browsers are now implementing that property makes it far less useful than it used to be for improving performance. It's moved from a useful hint to toss elements over to the GPU for faster processing to one that acts more like an !important flag for browser rendering... not terribly helpful in most cases.
  9. OK, this is good: while immediateRender:false doesn't help, autoAlpha seems to work under both 1.19.0 and 1.19.1! When I watch for DOM attribute modification, the first break in JS with autoAlpha under 1.19.1 happens at the same point as that for opacity under 1.19.0: line 2611 in CSSPlugin. It seems that the problematic pathway through that plugin is corrected with autoAlpha and the opacity portion of the tween is no longer skipped. I think there's a deep, obscure bug somewhere in TweenMax relating to skipping opacity, but it seems it can be bypassed with autoAlpha. I can run identical co
  10. Yeah, I know it's not helpful to be unable to duplicate it in a CodePen, but I'm hoping that one of the developers can think of the possible triggers for skipping opacity in a tween and if any of those changed in this TweenMax update. I've simply run out of ideas on what is causing it to skip that portion of the code since it doesn't seem to be either the CSS or the immediate JS. Since there are thousands of lines of Javascript that make up the entire web app, I'm hoping for a hint about other places to look for what could be the cause. Thanks for checking!
  11. I'm looking for any suggestions as to what might cause the bug I'm currently experiencing in TweenMax 1.19.1 -- I've run out of ideas. Here are the basics: I'm doing a TweenMax.staggerFromTo transformation that simply moves several elements from -20px and 0 opacity to 0px and 1 opacity. The classic "fade in from the left." The animation runs perfectly except that, with the most recent update to TweenMax, the opacity portion of the tween is being skipped altogether. The opacity of the elements is never modified and, even with clearProps not being used, opacity is not left in the Styles attr