Jump to content
Search Community

BaskingShark

Business
  • Posts

    14
  • Joined

  • Last visited

About BaskingShark

Recent Profile Visitors

1,609 profile views

BaskingShark's Achievements

  1. My turn to apologize for the delay -- we had our own launch that took over for awhile. I finally got a chance to test out your beta and it works great! It solves the problems I was having on mobile with viewport height without compromising on desktop. Thanks!!
  2. So here't the thing: after banging my head against CodePen for a couple hours trying to reproduce what I'm seeing, I realized I can't make a demo there for you. CodePen sets the body of the document to 100vh with overflow: hidden and then wraps the user content in an iframe with 100svh, effectively insulating the GreenSock code from any mobile browser height issues. It's sort of a built-in normalizeScroll(). I can show you a page in production using v3.12.1 that works correctly: https://poply.com/event_templates/76/preview and highlight the code that GreenSock adds to pin the top section: <div id="template_intro" class="template_intro"> <div class="pin-spacer" style="order: 0; align-self: auto; justify-self: stretch; grid-row-start: auto; grid-column-start: auto; grid-row-end: auto; grid-column-end: auto; z-index: auto; float: none; flex-shrink: 1; display: grid; margin: 0px; inset: auto; position: relative; flex-basis: auto; overflow: visible; box-sizing: border-box; width: 390px; height: 664px; padding: 0px;"> <div id="template_intro_wrapper_outer" class="template_intro_wrapper_outer" style="translate: none; rotate: none; scale: none; left: 0px; top: 0.001px; margin: 0px; max-width: 390px; width: 390px; max-height: 664px; height: 664px; padding: 75px 0px; box-sizing: border-box; position: fixed; transform: translate(0px, 0px);"> <!-- content --> </div> </div> </div> then compare that with the code that's added with no other change than upgrading to v3.12.2: <div id="template_intro" class="template_intro"> <div class="pin-spacer" style="order: 0; align-self: auto; justify-self: stretch; grid-row-start: auto; grid-column-start: auto; grid-row-end: auto; grid-column-end: auto; z-index: auto; float: none; flex-shrink: 1; display: grid; margin: 0px; inset: auto; position: relative; flex-basis: auto; overflow: visible; box-sizing: border-box; width: 390px; height: 664px; padding: 0px;"> <div id="template_intro_wrapper_outer" class="template_intro_wrapper_outer" style="translate: none; rotate: none; scale: none; left: 0px; top: 81px; margin: 0px; max-width: 390px; width: 390px; max-height: 664px; height: 664px; padding: 75px 0px; box-sizing: border-box; position: fixed; transform: translate(0px, 0px);"> <!-- content --> </div> </div> </div> The only difference is the "top: 81px" on "template_intro_wrapper_outer" -- the height of the address bar in mobile safari -- that's included by the newer code and that's what throws off the rest of the page. It basically moves all my content down and makes the footer inaccessible since I have to wrap the page in overflow: hidden to accommodate other animations. I do have normalizeScroll set to true for mobile browsers to make this complicated layout work, so I'm wondering if that's the issue. Maybe a better solution would be to have ScrollTrigger use 100svh in calculating height when normalizeScroll is true, and 100vh when false.
  3. In 3.12.2 there was a change made to the way ScrollTrigger calculates the viewport height: While it's great trying to remove some of the "jumps" in mobile with the show/hide behavior of the address bar, this was a breaking change for me since the new method makes it almost impossible to fire triggers properly based on the bottom of the visible viewport or to pin items that are set to take up the full viewport space by using JS hacks like the one described here https://css-tricks.com/the-trick-to-viewport-units-on-mobile/ I don't have a perfect solution, since mobile browser height is an absolute mess, but I still need a way to pin and trigger elements based on the perceived viewport, including the address bar, not the actual one that is the height of the browser window. While I know that 100vh is technically correct, the users just see that pins are getting cut off at the bottom or not firing. Would it be possible to add a new option to select the way that mobile browser height is calculated? Right now I'm frozen at v3.12.1 since I have several designs that call for perceived viewport height pins on mobile.
  4. 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!
  5. 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?
  6. 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 performance problem or a discouraged feature. I use that technique fairly frequently (although not on the html element) to keep changes to the DOM display in sync with animations. For example, switching tabs where a single timeline has a fade out animation, a class change to adjust layer stacking, hidden elements, pointer-events, etc., then another animation to fade in the new content. Are class changes in a timeline something to actively avoid? As for changing classes on the html element, as I said, it's rare but I have a couple of cases where I need to make some global change to all elements on a page in sync with an animation. For example, I have a waiting indicator that appears when changes are being saved to the backend. I animate it in while setting a class on the HTML tag that fades and locks all buttons and form fields on the page. When the API returns successfully, I animate out the waiting indicator and remove the "waiting" class to restore editing. I have something similar for animated popup boxes that require a modal state preventing interactions and animations from running beneath the popup. Setting the class within the timeline in those cases is just a convenience and I can easily move the action to a separate line outside of TimelineLite, but since I've been used to doing things like "+=waiting" in set() if I'm already running a timeline, I just kept up with the practice. Thanks!
  7. 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 to execute 'appendChild' on 'Node': The new child element contains the parent" error. Line 1366 ends up trying to append the HTML element to the HTML element. I can see that v.2.0.2 didn't call "_getMatrix" at all on set() and definitely not for a simple class addition or removal. Here's an example that will break every time: const waitContainer = $('.waiting_container'); const waitEnd_tl = new TimelineLite() .to(waitContainer, 0.2, {opacity: 0, ease: 'easeOut'}) .set($('html'), {className: '-=waiting'}); If you run the CodePen in debug view, you'll get the error after 2 seconds.
  8. 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 tested web app, then it’s bound to hit other people as well and similarly mystify them.
  9. 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 target) || p === "transform" || p === "x" || p === "y" || p === "width" || p === "height" || p === "className" || p === "border") && (!_plugins[p] || (_plugins[p] && _plugins[p]._autoCSS))) finds opacity in the target and doesn't add it to vars.css. It gets skipped. Maybe this is now the desired behavior? I tend to think that adding a non-standard property to a DOM element is probably going to cause other problems down the line, like it did in my case. Whew! That was a monster to find.
  10. I've seen the same behavior on macOS 10.12.3 with both Chrome 56.0.2924.87 and Firefox 51.0.1. Thanks!
  11. 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.
  12. 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 code under 1.19.0 and 1.19.1 with the only difference being "opacity" or "autoAlpha" -- the first jumps past the opacity tween code, the second activates it. I wish I could isolate the problem in a Codepen since I'm sure other people could benefit if the root cause could be found, but for now this solves the issue and lets me keep working. Thanks!!
  13. 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!
  14. 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 attribute after the transformation. The result is that the elements appear on the screen, then move 20 pixels to the right in sequence with no fade in. Some additional information: This bug appears in 1.19.1 only. I can switch back to TweenMax 1.19.0 and it won't appear, switch again to 1.19.1 and it will. So it's something that changed between this version and the last. I've tested in on Chrome and Firefox so it isn't just a single browser. While I've copied the basic situation in a Codepen, I cannot seem to reproduce the bug. There's a lot going on on this page, but no other modifications to this element take place before the Tween with the problem. I've tried adding every CSS attribute assigned to the real element to the Codepen element and I've reproduced the nested function/promise/function structure of the js, but I can't get the issue to appear. The attached pen does show the context, at least. If I set the debugger to break on attribute modification, in 1.19.0 it breaks first on the opacity part of CSSPlugin.js at line 2611. In 1.19.1 it breaks on the matrix portion of CSSPlugin.js at line 1722, skipping the opacity code entirely. If I try to modify only the opacity and not the position, it does nothing at all and no attributes are modified on that element. It's definitely only the opacity tween that's affected. Any thoughts on what has changed in 1.19.1 that could lead to opacity being skipped in a staggerFromTo under certain conditions? I'd prefer not to have to freeze Greensock updates on this project and stay with 1.19.0 for good, but I've spent more than a day on this and I still can't figure out what might be causing this deeply obscure problem.
×
×
  • Create New...