Streaming live at 10am (PST)

Interactions accross breakpoints

Hello everyone, here I am again.

@vincent , I know you’re a busy guy, but could you please have a look at this? I definitely would appreciate it

New issue: I created animations based on “When scroll into view” to most of my website content. As I realized it was pretty heavy on mobile devices, I disabled those interactions on mobile devices. Now, I can’t see any content on the mobile version unless I turn the animation back on. (Which I really don’t want to).

Is this a bug or am I really supposed to create duplicated elements, one to use with animations and the other not?

Thanks for your help in advance.


Here is my site Read-Only: LINK

Live preview of the website: LINK

(how to share your site Read-Only link)

I am not Vince but I know what’s wrong anyway :slight_smile:

The problem is with the initial states of the animations. Initial state in your case is invisible element that is appearing when elements scrolls into view, right? So the problem is initial state is served no matter if interaction itself is disabled. So you have all your objects in the limbo of initial state which is “invisible”. SO that’s that. For built-in interactions you have used, there are no workarounds.

3 Likes

Gosh that’s terrible. Here it is something that people from Webflow could try to solve huh?

Thanks for the heads-up.

Yep.

I see no reason for it to be as designed. If you wanted an element to remain in its initial state for devices where the interaction don’t run, you’d set the initial state in the style panel, not using the IX.

@Jeandcc I haven’t looked at your site and don’t know what it takes, but maybe make an interaction that will only run for device and that is setting all faulty elements in the state you want them, right at page load. And don’t use initial state for this IX of course, just actions with no delay.

Don’t know if it works.

1 Like

Just a thought, have you tested on mobile? Because inital state are set for the viewport at load. And if you resize the viewport, with the browser or using Webflow, it doesn’t reload the page, so the states are what they were at load. If the page is loaded at the device size, maybe the IX sin’t played and the initial states aren’t set.

Can you please test this and tell us?

1 Like

I tried doing what you suggested, but it didn’t work. The website stills inheriting the visibility of the element from the interactions panel, instead of the layout panel. I think it’s worth mentioning that I’m currently using Webflow built-in animation such as the “slide” or the “fade in/out”

Here’s a video from the mobile version.

Only elements that don’t have animations are appearing on the published version of the website

The thing about initial state is that this is the way for webflow to deliver will-change property. I think you know that it is a great way to reduce a hardware stress when redrawing the page with animations (instead of redrawing full page you tell your hardware to load the will-change object into a separate layer that is then being redrawn separately thus saving precious fps on animation-heavy pages). If WF were to remove this, there would be no way to assignwill-change at all :frowning:

@Jeandcc

You may either redo the animation manually, not using initial state, or just leave the animation. Does it look that bad on mobiles?

I understand what you’re saying and I agree that this is a important feature.

I’m thinking about duplicating and then ‘displaying - none’ the elements with animations.

When I try to load on mobile , it stutters a bit , and even tho it’s not that much, it’s kind of important when it comes to UX.

Thank you both for your inputs. Have a great week

Well, this is not the best solution, updating the content would be a nightmare. The interactions you are using are simple enough for replication, just do them manually and not use initial state but rather set the initial state of objects with the styles properties. Then on the mobile breakpoint change this style to be visible and at the right place and disable the interactions for that breakpoint. It’ll work.

I understand your point of view.

I don’t wanna be that guy who finds problems in everything, but let’s say that one of the animations would be a combination of sliding/fading in. So, if I were to set the ‘initial state’ through the style panel, I wouldn’t be able to see the content I’m editing , once the content would be ‘styled’ to 0% opacity.

Does that make sense?

1 Like

Anyways, I figured out a workaround to it.

I combined your suggestion (@dram) about creating a custom animation with an idea that I had.

Instead of setting the initial state through the style panel, I created a “2-Step animation”: The elements will be styled as the way I want them to be, meaning opacity 100% and ‘no transforms applied’. Then I created an animation of the properties I want to change. The first step would be a 0s animation with 0% offset, moving the element to the left (in my case) and making its opacity go down to 0%. Then, I created the animation I wanted (In this case, a sliding effect)

That way, I will be able to see the content I’m editing when I’m not messing with the interactions panel, and also disable certain animations across breakpoints without making anything disappear.

This is also not ideal, because now we see a jumping divs for a split second (I do any way) when they first appear on screen and then the ix kicks in and sends it to your manually set initial state.

I usually just turn off the transforms and styling I apply to the elements that moves them/chages opacity until publishing so that I can keep working on them meanwhile. Its just a thing to keep in mind when working on a layout.

Yeah, that’s a bit of a hassle after all.

1 Like

Well, it’s far from ideal what I’ve came up. In my opinion, at these times we’re living , we shouldn’t have to mess around with things to fix something. This should be something that people from Webflow should think about when implementing new features and updates. Programmers are the future of humanity hahaha

Oh, absolutely. I’d love to see this problem solved somehow by wf dev team.

What I’m saying is you can tackle this in two ways - first will make it easier for you, as a designer (your approach), second will make your product behave correctly for end users while somewhat inconveniencing your work process (my approach). That is all :slight_smile:

1 Like

You did that, right?

Yes @vincent ! I even posted a video directly from my phone

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.