Jump to content
Search Community

determin1st

Members
  • Posts

    56
  • Joined

  • Last visited

Posts posted by determin1st

  1. 1 hour ago, SC_74 said:

    Doesn't work!

     

    Prove it!

     

    if you .play() timeline later, create it {paused:true}. also, i dont get why you use .from() call. also, you can add single tween to timeline using .to() method. also, dont hope that GSAP will handle state management for you, better, control it separately. also, everything you do with jquery there, can be done with plain JS..

     

  2. You should create single timeline with all tweens as PointC sayed ^ for better control but I dont recommend to use reverse, instead, create another "reverse" timeline and manage state using internal variable (it's simpler than adding/removing classes to DOM element). After that you have several options when state changes:

     

    1. block state change if some of timelines is active.

    2. kill() or finish opposite active timeline and start target state change timeline.

    3. combine timelines, but it's not needed as it is only two states.. (on/off)

     

    also, you can re-create timelines every time instead of using same timeline instances (they will overwrite each other as they use same targets) but you have to hold those instances in memory for further checks.

     

    • Like 2
  3. 50 minutes ago, GreenSock said:

     

    Absolutely - because invalidate() delivers a totally different result which isn't intuitive in many cases. Plus invalidate() is expensive performance-wise (it must flush the recorded start/end values and re-query and re-record them). When you replay an animation, typically people expect it to look the same as it did the first time. And imagine if your timeline is at its end state and then you invalidate() and try playing again - it's probably gonna look really weird because it's already sitting at its end state...so the new starting values will match the end state and you'll likely get no animation (though of course that'll get more complex if you've got other tweens on the same values in a sequence that are all invalidated()). See what I mean?

     

     

    Sure, I see your logic and I can argue that, but as you said it's about intuition, okay, let it be.

     

  4. Just now, Acccent said:

     

    I assume it's for both for performance, and also because these are two distinct behaviours and both can be useful in some cases.

     

    Here's a follow-up question: assuming there's a choice between a percent-based timeline, that's responsive by default, and one that uses x and y but needs to be recreated every time, what's the better approach? I guess both performance-wise and when it comes to workflow? (This may be subjective!)

     

    i think, it's the same speed, because element's computed style is always returned in pixels, so the initial % needs to be determined together with the ending %, but this is done inside the lib, more flexibility, less codewriting.

     

     

  5. 18 hours ago, Acccent said:

    I'm afraid I don't really understand a single thing of what you're suggesting, nor do I really get how a solution that takes so many lines and setup could be easier or more intuitive than just 3 tweens triggered with pointer events... Sorry! Good luck though :)

     

    I don't suggest. Just answering. It's not easier, it's more flexible. We do different things.

     

    • Like 2
  6. 13 hours ago, Acccent said:

     

    I mean, you can have :hovered, :focus, :hovered:focus, :hovered:checked, :focus:checked, :hover:focus:checked. That seems like a lot, and I'm sure I'm forgetting some.

     

    You can have :hovered instead of .hovered if you are going to animate with CSS transition, but you are not, right? (You want to animate with GSAP) Also, these standard pseudo-classes are very limited in name/number. They are separated from browser events, so you won't be able to implement complex logic.

     

     

    13 hours ago, Acccent said:

     

    And what about when you want different components of an animation to animate at different speeds?

     

     

    You and I use queue for that. The difference, i suppose, that we use it differently. You:

    // define, init, assemble, run
    timeline.to(node1, {anim1});
    timeline.to(node1, {anim2});

     

    I write more data-oriented way:

    // define
    hover = [{anim1}, {anim2}];
    ...
    
    // init
    hover[0].node = node1;
    hover[1].node = node1;
    ...
    
    // assemble
    timeline = redSock.queue(hover);
    ...
    
    // run
    timeline.play();

     

    Here, I had to write "queue" function, which interprets a sequence of tweens, given as a parameter and creates a timeline.

    Sure, to have several animation/transition steps on the same target there must be several CSS classes. But they are single state to the widget and don't increase nesting inside CSS file structure if you want to animate different CSS properties.

     

    In fact, developing an interface.. creating of reusable/complex widget will require animation of several targets.

    Making several steps (for the same target) is not obligatory 99%.

     

    Look at the experimental widget I posted above, the hover animation defined as:

          hover: [
            {
              // TITLE node
              duration: 0.4,
              to: {
                className: '+=hovered',
                ease: Bounce.easeOut
              }
            }, {
              // CONTENT node
              position: 0,
              duration: 0.4,
              to: {
                className: '+=hovered',
                ease: Power2.easeOut
              }
            }, {
              // PANEL node (container of TITLE & CONTENT)
              position: 0,
              duration: 0.6,
              to: {
                className: '+=hovered',
                ease: Power2.easeOut
              }
            }
          ],

     

     

    13 hours ago, Acccent said:

    And what about when you want different components of an animation to animate at different speeds? For instance, say I have a simple semi-transparent button. I want it to linearly transition to 100% opaque AND scale with a bouncy ease over 0.3s when hovered. But when I stop hovering, I want it to slowly go back to its previous opacity and scale, this time with a linear transition for both and over 0.5s instead of 0.3.

     

    I don't know what means "when I stop hovering" - you can't really, stop hovering, because events are discrete. The only way it can be interpreted, that pointerenter occured, you started animation and in the process of animation (it's not finished), pointerleave occurs. It does not differ from unhover effect, which could be:

     

          unhover: [
            {
              duration: 0.4,
              to: {
                className: '-=hovered',
                ease: Power2.easeIn
              }
            }, {
              position: 0,
              duration: 0.4,
              to: {
                className: '-=hovered',
                ease: Power2.easeIn
              }
            }, {
              position: 0,
              duration: 0.4,
              to: {
                className: '-=hovered',
                ease: Power2.easeIn
              }
            }
          ],

     

    But it's not, probably, what you thought about, as you were speaking about multi-step animation for the same target.

    To do that, hover can be morphed into this:

     

        ...
          hover: [// timeline abstaction
            {
              // TITLE node
              group: [ // nested timeline created here
                {
                  duration: 0.3,
                  to: {
                  	className: '+=hoverStep1',
                  	ease: Bounce.easeOut
                  }
                },
                {
                  duration: 0.5,
                  to: {
                  	className: '+=hovered',
                  	ease: Power0
                  }
                }
              ]
            }, {
              // CONTENT node
              position: 0,
              duration: 0.4,
              to: {
                className: '+=hovered',
                ease: Power2.easeOut
              }
            }, {
              // PANEL node (container of TITLE & CONTENT)
              position: 0,
              duration: 0.6,
              to: {
                className: '+=hovered',
                ease: Power2.easeOut
              }
            }
          ],
          ...
          
          

     

    This adds complexity, which is not obligatory to interface object, imo. In the CSS you will need two classes:

    /* nesting for intersecting props */
    .hoverStep1 {...}
    .hoverStep1.hovered {...}
    
    /* or */
    
    /* non-intersecting props */
    .hoverStep1 {...}
    .hovered {...}

    ..and corresponding unhover queue, which reverses both classes.

     

     

    13 hours ago, Acccent said:

    And I want it to do a tiny "shake" animation when I click it if it's disabled. How would I achieve that with only className?

     

    Okay, use manual awesome effect (in click event handler), it doesn't change any visual state..

    Still, it can be defined and played the way I described above but without className.

     

     

    13 hours ago, Acccent said:

    Again, apologies if I misunderstood or missed something, I'm just trying to wrap my head around what you have in mind.

     

    No need. Im trying to create a reusable app framework and widget library. It's not required to know how framework works if you only want to use widget. It works jquery-like. You call a function, pass data and options.. that's all. No need to install/configure lots of stuff.

     

     

     

     

     

  7. 2 hours ago, Acccent said:

     

    Why are there two declarations for .green-state and .red-state in your CSS? Why does a box with both .red-state and .green-state become red, not green? I mean, I understand the CSS, but isn't is it way less intuitive to do it that way? If I want a box to go from green, to red, to blue, to yellow, to purple... would I have to write 5 nested classes? Just wondering if I missed something :)

     

    (Also, I feel like there's a lot of unneeded aggressiveness in this thread – could use some humility... but I'm no mod)

     

    That are just base rules of cascade. Two classes replace one, as .class1 < .class1.class2. so, when you have .green, it's green, when you have .green.red, it's red, because two classes are bigger. It can be Less intuitive only when you create classes for multi-step animation which are not bound to the *real* state. The real state always matters something. In that example it means only "pulsing box on page load" or "awesome effect", so it's not intuitive.

     

    The combined class number of 5 (.a.b.c.d.e) - can't imagine... it means that widget may have 5 states applied simultaneously.

    take checkbox, it may be: hovered, checked, disabled, hidden, focused(keyboard)... but not all of them.. it may be hovered+checked, but not hovered+disabled or hovered+hidden. So, you have to, if you find out something great.

     

    The nesting (.a .b .c NOT .a.b.c), may be very deep, because of DOM structure of your widget and state combinations.

    You don't have to nest if you know that these class names will be unique on page.

     

     

×
×
  • Create New...