Streaming live at 10am (PST)

Using percentages for interactions 2.0 seems to break them


#1

The goal.
I need to reliably move elements of different sizes by distances proportional to their dimensions, using interactions 2.0. So if an element’s width is 20 px, it needs to move 20 px, and if I later change its width to 30 px it now needs to move 30 px. I need to do this because it’s the only way to synchronize movement between elements of variable sizes when making them disappear with overflow:hidden.

The reasoning.
On paper, it sounds simple enough. I tell the interaction step to move the element by, say 100%, or some other percentage. Done, right? I hate to spoil it to you, but things don’t work out as they apparently should.

The setup.
The link is set with an initial movement state of “110% X” (moving it to the right).
Upon hover, after a delay of 0.0s and with a transition time of 1.4s (these numbers are important), it’s set to move back to its natural position, i.e. “0% X”.
Upon hover out, after a delay of 0.0s and with a transition time of 1.4s (same numbers as before, still important), it’s set to move back to its initial movement state, i.e. “110% X”.

What actually happens.
To make a long story short, it bugs out. Specifically, the timeline becomes something more along the lines of a delay of 1.2s and a transition time of 0.2s, with a bit of funky lag to boot.

What I’ve tried.
I’ve tried changing the timeline, and I’ve discovered that adding some substantial delay (2s) makes the whole operation move as specified, but adds an incredible amount of lag.
I’ve tried changing the easing type and the percentage of movement and, while I have tried only a few combinations, it doesn’t seem to change things.
I’ve tried to change the “Affect:” setting from “class” to “select element” and that seems to cause the actions to not register at all.

Is this normal? Is there a solution I’m not seeing?


The public share link.
For your viewing and testing pleasure.

Thanks!


#2

Hi @Moscangelo

OK, so to be blunt… you have a lot of conflicting stuff going on which is causing the issues.

I’ll record a video to go through each point. It won’t be edited, so bear with me! :grimacing:

CloudApp


#3

@Moscangelo Video link in post above, excuse the waffling on.

If you move something further past 100% (i.e 110%) then it’s going to take longer before it appears.
If you moved it 200% it’s going to take twice as long to appear. So even though you say a delay of 0s, and 1.4 seconds, some of that 1.4 seconds is moving it the uneccesary 10% into to div block.

It’s not bugging out, it’s taking longer because you told it to go further. :slightly_smiling_face:


#4

Alright :thinking: That seems weird to me, as CSS animations and Interactions 2.0 have never given me any issues for as long as they affect different parameters.

At any rate, I did what you suggested and… the problem is still there? I can’t see any difference, it’s extremely delayed, rushed and laggy just as it was before.

As a sidenote, everything you deleted and edited away was intentional - even the div width and height, which helps center the CSS animations. So I’d really rather not delete any of it if possible.

The important part here is, I think, that the interaction 2.0 only starts bugging out when I use percentages. It works flawlessly otherwise, with wv or px or anything else. So still, I’m not seeing a conflict between interactions and CSS animations.

I’m sorry, but that’s definitively not what’s happening on my screen. It’s not delayed by 10% because I told it to go 10% further, it’s delayed by whole seconds and then rushed in a fraction of a second. This happens with 100%, 110%, or 50%.

Would you mind me showing what happens when you hover over the navbar at this address? I’m starting to doubt we’re seeing the same things http://sarti-2-0-temp.webflow.io/

Here is what I see [edit: while using Chrome, latest update in incognito mode]:
2018-04-17_00-42-52


#5

Hey @markos84uk, you were right about the conflict!

I finally had time to test several settings, removing one thing at a time and using “control elements” with very little styling and no external animations for comparison.

It turns out, Transition (All Properties) really was the culprit! I thought I deactivated it when I first tried your method, but I must’ve missed it on the text boxes. And yeah, only the relevant elements (the text boxes) were conflicting, everything else can remain unchanged and it all works as intended (although I will change the header over to IX 2.0 too, just to be sure).

Thanks so much!