Jump to content
GreenSock

Yashi-2

Correct Syntax to remove multiple classes

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi, this is a noob question. I want to remove multiple classes at once. how do I do it,

 

is this right? if not what is the correct syntax 

 

tl.to(elem, 0.3,{className:"-=open,white"});

 

Link to comment
Share on other sites

tl.to(elem, 0.3,{className:"-=open white"});

 

Use spaces instead of comma.

 

EDIT: I guess there is some other way, see following Pen. It works if your class attribute string is same but doesn't work if there is any difference in characters of any class, or even if order is changed.

 

See the Pen RjpOKO by Sahil89 (@Sahil89) on CodePen

 

 

  • Like 3
Link to comment
Share on other sites

yup that is my main issue.  the order of the class names. what if I use double className attribute. it's an antipattern. will that be ok?

Link to comment
Share on other sites

it's ok now. I did that with jquery. Jquery can handle multi-class removals. and it doesn't require order. it just removes them. thanks @Sahil

  • Like 1
Link to comment
Share on other sites

There is currently no logic in place to check for individual class names so it must follow the order found by doing this.

var className = myElement.getAttribute("class");

 

Just an FYI, changing class names without jQuery is now pretty easy. Won't work on SVG in IE though.

myElement.classList.add("foo", "bar");
myElement.classList.remove("foo", "bar");

 

  • Like 6
Link to comment
Share on other sites

Here is how you can remove multiple classes using jquery

 

$(elem).removeClass('class1 class2');

 

  • Like 1
Link to comment
Share on other sites

@Sahil correct and also order doesn't matter. but if you can avoid jquery try to use @OSUblake native javascript solution. it's the correct way.

  • Like 1
Link to comment
Share on other sites

yes sure and thanks, @Jonathan. for GS I think this is must have but without any order to remove multiple classes. like how JQ and native-js handle this thing

Link to comment
Share on other sites

@Jonathan I thought it was never meant to handle multiple classes. If I remember correctly from around 2015, removing multiple classes were not supported. I only gave it a try thinking maybe it may have changed.

Link to comment
Share on other sites

No worries .. it never hurts to get clarification on something like this, since @GreenSock's Jack and @Carl have been improving the GSAP library every day ;)

 

I mean if it was just non animating multiple classes then i would just use the vanilla JS way of classList remove or add. But for animating multiple classes, thats why I asked the Big Wigs :) 

Link to comment
Share on other sites

You can remove multiple class names with 2 separate tweens:

 

TweenLite.to(".green", 2, {className:"-=open"})
TweenLite.to(".green", 2, {className:"-=white", overwrite:"none"})

 

See the Pen Zaygme?editors=0010 by GreenSock (@GreenSock) on CodePen

 

This is the first time we've heard of this so we will have to weigh the pros and cons of supporting multiple classes in one line.

Thanks for bringing it to our attention.

 

 

 

  • Like 4
Link to comment
Share on other sites

Actually I had struggled with this a lot when I new. And I think many people do too, especially those who come from jQuery background. Also I had tried to add and remove classes at the same time, and had seen few questions about it as well.

 

Not saying you should support it because my way of looking at animations has changed a lot so I don't remember last time I had to tween multiple classes but docs should be updated with this clarification.

  • Like 1
Link to comment
Share on other sites

Big Thank You to @Carl for his solution, using the overwrite special property after the first add className  :D

 

Taken from TweenMax Docs special property overwrite:

 

overwrite:  String (or integer)  - Controls how (and if) other tweens of the same target are overwritten. There are several modes to choose from, but "auto" is the default (although you can change the default mode using theTweenLite.defaultOverwrite property):

  • "none" (0) (or false) - no overwriting will occur.
  • "all" (1) (or true) - immediately overwrites all existing tweens of the same target even if they haven't started yet or don't have conflicting properties.
  • "auto" (2) - when the tween renders for the first time, it will analyze tweens of the same target that are currently active/running and only overwrite individual tweening properties that overlap/conflict. Tweens that haven't begun yet are ignored. For example, if another active tween is found that is tweening 3 properties, only 1 of which it shares in common with the new tween, the other 2 properties will be left alone. Only the conflicting property gets overwritten/killed. This is the default mode and typically the most intuitive for developers.
  • "concurrent" (3) - when the tween renders for the first time, it kills only the active (in-progress) tweens of the same target regardless of whether or not they contain conflicting properties. Like a mix of "all" and "auto". Good for situations where you only want one tween controling the target at a time.
  • "allOnStart" (4) - Identical to "all" but waits to run the overwrite logic until the tween begins (after any delay). Kills tweens of the same target even if they don't contain conflicting properties or haven't started yet.
  • "preexisting" (5) - when the tween renders for the first time, it kills only the tweens of the same target that existed BEFORE this tween was created regardless of their scheduled start times. So, for example, if you create a tween with a delay of 10 and then a tween with a delay of 1 and then a tween with a delay of 2 (all of the same target), the 2nd tween would overwrite the first but not the second even though scheduling might seem to dictate otherwise. "preexisting" only cares about the order in which the instances were actually created. This can be useful when the order in which your code runs plays a critical role.

:)

  • Like 3
Link to comment
Share on other sites

thanks, @Sahil @Jonathan and @Carl to clear this out. I was struggling to do this with a single tween. I think it involves two tweens. but this makes sense now. big thanks to @Carl .. :) :)

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×