[Arrg. TimelineMax onComplete being fired more than once]

Oops.

 

This is the one, I presume:

this.tl.eventCallback("onComplete", function () {
console.log ("Should fire once at the end of the timeline" );
} );

[Arrg. TimelineMax onComplete being fired more than once]

I was about to launch my site when I realize some inconsistent behavior with the onComplete callback. It works fine (i.e., fire the onComplete event just once) about 90% of the times in Chrome, and it is even more inconsistent on Safari and Firefox. For the latter two browsers, onComplete is being fired more than once often, and sometimes twice, and sometimes thrice, and sometimes once. 

if (this.tl) {
this.tl.invalidate();
}

this.tl = new TimelineMax({delay: 0});

this.tl.staggerTo(arrayOfElements, 0.55, {
onComplete: function () {
// The Console is logging this more than once sometimes, and sometimes just once, depending on the browser
console.log ("staggerTo Complete");
},
autoAlpha: 0,
y: "50",
ease: Expo.easeOut
}, 0.06, "+=0.08");

[scrollToPlugin is buggy on Safari]

The scrollToPlugin is buggy on Safari, when scrolling to a section of a long page. The plugin works perfectly on Chrome and Firefox. So there is definitely an issue with Safari, not with my code .

 

Specifically, sometimes when you scroll to a div or element, the page doesn't scroll all the way; it will just scroll a bit and stop. Other times it may work. My code is simple:

TweenMax.to(someElement, 0.9, {
scrollTo: {y: scrollToVal},
ease: Expo.easeInOut
});

I tested on the latest version of all three browsers. Safari 8.0.x is the culprit.

[ScrollToPlugin doesn't work with shadow dom]

OSUblake, Thanks very much for taking the time to create the thorough example. You helped me find the solution. This method, elem.getBoundingClientRect(), which I have never seen or heard of before, was key to the solution. However, that alone didn't solve the problem only because we still had to subtract the distance from the top of the element to the top of the window, which the following function (credited to http://javascript.info) does:

function getOffsetRect (elem) {
var box = elem.getBoundingClientRect(),
body = document.body,
docElem = document.documentElement,
scrollTop = window.pageYOffset || docElem.scrollTop || body.scrollTop,
scrollLeft = window.pageXOffset || docElem.scrollLeft || body.scrollLeft,
clientTop = docElem.clientTop || body.clientTop || 0,
clientLeft = docElem.clientLeft || body.clientLeft || 0,
top = box.top + scrollTop - clientTop,
left = box.left + scrollLeft - clientLeft;

return { top: Math.round(top), left: Math.round(left) }
}

And since that function gets the correct scrollTo distance, we can use TweenMax's ScrollToPlugin (or any other scrollTo library or plugin) easily.

[ScrollToPlugin doesn't work with shadow dom]

Oops! I just tested the code I last posted and I noticed that the solution works on only native shadow-dom browsers. We have to use Polymer's polyfill library for selectors like :host * to work on non-native shadow-dom browsers. I will whip a solution for this that works inside Polymer. 

[ScrollToPlugin doesn't work with shadow dom]

So the solution is to iterate over the element's parents (piercing through the shawdow dom) until you get the eventual distance from the top of element to the window (scrollTop). Here is a jQuery pull request to fix the issue for the jQuery's offset method, which has the same problem that GSAP's ScrollToPlugin has:

https://github.com/jquery/jquery/pull/1976/files

 

The crux of the matter is this bit of code (Jack, if you do the same for the ScollToPlugin, that would be fantastic):

// We have element in ShadowDOM, need recursive traversal from element to its parent
if (elem.matches && elem.matches(":host *")) {
// Make sure it's not a disconnected DOM node
while (true) {
elemParent = elemParent.parentNode || elemParent.host;
if (elemParent === doc) {
break;
} else if (!elemParent) {
return box;
}
}
} else {
// Make sure it's not a disconnected DOM node
if (!jQuery.contains(docElem, elem)) {
return box;
}
}

[ScrollToPlugin doesn't work with shadow dom]

Thanks for the reply, OSUblake. 

 

Your example is different from the issue I reported. TweenMax is working fine with Polymer for everything besides scrolling with the ScrollToPlugin. The main issue is that the ScrollToPugin doesn't work when trying to scroll to a div located in a shadow dom (because element.scrollTop, which the ScrollToPlugin uses, is always 0).

 

Selecting an element is also not a problem. I can successfully use different ways, including the automatic-node-finding option you showed, to find or select a node.

[ScrollToPlugin doesn't work with shadow dom]

I am using the Polymer library to build a web app, using web components. I am trying to scroll to a particular div, but since the div is inside a shadow dom, GSAP's ScrollToPlugin doesn't reach inside shadow dom to find elements, so it doesn't work.
 
Browsers' native scrollIntoView Works
Some browsers have the scrollIntoView method, and for whatever reason, this is the only solution that is working for me. But of course it just jumps to the div; it doesn't scroll. I want to scroll gracefully.
 
Question
I want to use GSAP's ScrollToPlugin to scroll my page to a div that is inside a shadow dom. A correct reference to a shadow dom  (using Polymer) looks like this:

var myDiv = document.querySelector('custom-element /deep/ #myDiv'); 

// this works (native browsers' scrollIntoView):
​ myDiv.scrollIntoView(); 

Important Note

I am pretty sure the browser's native scrollIntoView method is not using element.scrollTop. The reason is that every solution that uses scrollTop doesn't work. The element.scrollTop property is always returning 0, since it sees the shadow dom as the root document.

 

I tried a couple of jQuery plugins and none of them works. They all use scrollTop (just as the GSAP's ScrollToPlugin does).

 

Whatever solution the browser's native scrollIntoView method uses seems to be the best way to scroll into view for elements within a shadow dom. 

 

Who can help me with this?

[Can the JS version of GSAP do grayscale?]

Well, I just gave it a very quick try and the elements are tuning black because the desaturation is being added more than once, it appears. I will get back to this later when I have more time to set it up properly. I have to complete another more urgent part of the project for now

[Can the JS version of GSAP do grayscale?]

Thanks, Jonathan. I am aware of the className property, which is just fantastic.

[Can the JS version of GSAP do grayscale?]

I thought of an easy way to make this work:

dynamically add a new class to all children and their children, and add the saturation to that class, so I can later remove the class easily to restore the color.

[Can the JS version of GSAP do grayscale?]

Adding Tweenlite ani does make the transition to grayscale more lovely.

 

I tried out your desaturate function on my page and it works fairly well on specific div elements. I could make it work for the entire web page, with a good bit of effort .

 

I did notice that the overall grayscale did not maintain the brightness level of each color. For instance, if we have a red box on a blue box, the red box is almost the same grayscale color as the blue box, so the red box, which is actually a button, is barely noticeable after the desaturation.

 

The bottom line is that this can work with some tweaking, but it does require some effort indeed, to desaturate the entire page.

 

Thanks very much; this is the best bet for now I supposed.

[Can the JS version of GSAP do grayscale?]

Thanks, Carl. It makes sense that GASP will not support experimental features. 

 

The canvas solution wouldn't work for me, I just want to target the body tag and desaturate the entire page, as I noted above to Jonathan.

[Can the JS version of GSAP do grayscale?]

 

See the Pen dkyKu by jonathan (@jonathan) on CodePen

 

 

Wow, Jonathan; that is a very impressive effort.

 

Thanks for the thorough explanation. I didn't study your desaturate function enough to know if I can just use it on any web page's body tag to desaturate the entire page. That is what I want do: target the body tag to desaturate the entire page (all of the body tag's children).

 

Can you tweak your desaturate function to do that?

[Can the JS version of GSAP do grayscale?]

I know we can easily remove the saturation from any movieClip in Flash with GSAP and thus turn the clip into a grayscale version of itself.

 

How can we do the same with the JavaScript versions of GSAP? Essentially, I want to change the color of a div and all its children into a grayscale color.

 

 

[There appears to be a bug when TimelineMac reverses DOM elements]

Thanks for extra bit of information, Carl. I agree that .children could be messy when there are other DOM elements besides the target elements that are children to the form tag. I will make of this.

 

And thanks for the clearProps explanation. Good to know.

[There appears to be a bug when TimelineMac reverses DOM elements]

Thanks very much for explaining the issue, Jamie. Your explanation sounds spot on. 

 

I didn't try your solution because i tried changing the z-index previously and it did not work. But I will give it a go.

 

The clearProps solution worked after I tried it. I did not see your post before I attempted the clearProps solution.

[There appears to be a bug when TimelineMac reverses DOM elements]

Excellent, Rodrigo!

 

That fixed the problem. Thanks very much for sticking with it and for solving the problem.

 

What exactly does clearProps do anyway?

[There appears to be a bug when TimelineMac reverses DOM elements]

Here is the CodePen example that shows the exact problem. Simply click on the select list after the animation completes:

See the Pen BAnJK by anon (@anon) on CodePen

 

Note that if you remove the TimeLineMax code, the select list drop-down works fine (it is above the submit button). But only after the reverse animation runs does the problem occurs.

[There appears to be a bug when TimelineMac reverses DOM elements]

Okay, I just reproduced the problem on CodePen.

 

I will post the CodePen link in a couple minutes.

[There appears to be a bug when TimelineMac reverses DOM elements]

No, I wasn't saying to not tween the submit button. I was saying that the drop-down from the select list is pushing the submit button down when it is expanded, and that is not normal. 

 

You can only see the problem I am here for if the select list does NOT push the submit button down. When the select list expands (as with all the examples on the selectize page), the select list works like a normal drop-down menu: it displays over the other items below it without moving the other items.

 

Right now we cannot see the issue because in the CodePen example, the select list is pushing the the submit button out of the way, instead of displaying the drop-down list over the submit button.

 

Do you understand the problem?

[There appears to be a bug when TimelineMac reverses DOM elements]

Thanks much. The submit button is moving, though. It should stay in place.

 

So, we have to get the drop-down list in the example to not push the submit button down. The submit button has to stay in place.

 

BTW, I am wondering why the submit button is moving in this example. I have never seen that.

[There appears to be a bug when TimelineMac reverses DOM elements]

Okay, now that we have established that TimeLineMax is working with that barebones setup, the last bit I left out was this:

 

I am using the Selectize jQuery plugin on the select list. I couldn't add it to the CodePen example, but here is the external js link:
http://cdnjs.cloudflare.com/ajax/libs/selectize.js/0.6.14/selectize.min.js

 

And this is the selectize JS code to add to the example:
 

$('select').selectize({
    delimiter: ',',
    persist: false,
    create: function(input) {
        return {
            value: input,
            text: input
        }
    }
});

Add these to the CodePen example and let's see how it goes.

[There appears to be a bug when TimelineMac reverses DOM elements]

Sorry about not posting enough code earlier.

 

The project is not online, but the code below illustrates the issue:

 

The HTML:

<form id="submitForm">
<input type="text" class="form-control" id="title" placeholder="Title:">
<input type="text" class="form-control" id="message" placeholder="Message:">
<select>
  <option value="item1">Item 1</option>
  <option value="item2">Item 2</option>
  <option value="item3">Item 3</option>
  <option value="item4">Item 4</option>
</select>
<button>Submit</button>
</form>

 

The JavaScript:

 var twiAni = new TimelineMax ();
    twiAni.staggerTo($("#submitForm").children(), 0.4, {y:"-=100"}, 0.04);

// And then later, the reverse code:
twiAni.reverse(); 

Again, the problem is that after the reverse, the submit button is above the select list drop-down items.

[There appears to be a bug when TimelineMac reverses DOM elements]

Hi RHernando, I just uploaded the screenshot again. It is attached to the original post above.

 

Could you set up a codepen or jsfiddle in order to see this?, or perhaps a live page?.

 

 

Well, that would take a bit of effort to reproduce. I will eventually if all else fails.

 

Just a blind suggestion, but try staggerFrom perhaps that could help.

 

I can't use staggerFrom because it is a completely (the opposite of) different animation from staggerTo, and I need staggerTo. My animation is working perfectly fine. The only issue is what I noted in the post above.