The slider on the homepage works fine, when the slider or the button in the slider itself is not hovered… however I need the button to be clickable so this is not an option. I have never experienced this problem while using webflow, but it’s driving me nuts!
This is the website with the existing problem. https://kleijntjetravel.webflow.io/ Try refreshing the page when not hovering on the slider and the problem is not there.
Any help or suggestion is appreciated! Thanks in advance
Which part of the page is the Slider, and which part is built with interactions?
We have been making changes to Slider in the past week, in order to improve accessibility. The idea with pausing slides when hovered, is that you might want to click on one slide’s button, but it changes right before you click. Or you might be reading some content, that moves before you are done reading.
So pausing on hover is by design. I’m not sure what you are having trouble with in the link posted.
I have tried making some changes and I have made the content and the image slider into different parts. The problem was that the slider did not return to autoplay after ive stopped hovering the button.
I have a slider with just images that has not button in it so I don’t want it to stop. Might be an idea to have a check box in the slider settings to say something like ‘pause on hover’?
If webflow made this into a default it would be one of the dumbest thing they’ve ever done.
I haven’t seen that many people asking for pause on hover, because why on earth would that be a thing?
it messes up the entire UX, confuses the site visitor completely, and destroys design concepts.
It took me a couple of days to even realize this was a feature! i thought it was a bug.
WE NEED TO REVERSE THIS ASAP! or at lease give us a work around instead of forcing on an entire community these arbitrary design functions 90% of webflow never asked for!
@GrahamB@Nir - This is definitely the right move, as most sliders include calls to action that need time to click. Using websites that contain clickable elements in sliders that don’t stop is terrible UX, so defaulting to this behavior is welcome.
You can get around this by giving your slider a negative z-index so it sits behind an element with a transparent background—which prevents the hover from triggering and stopping the slider. You can see an example here:
Not sure if this is what @forresto and the Webflow team consider an appropriate solution, but it should help solve your issues without resorting to custom code.
No @mikeyevin
the right move is to give us options, not force it.
Especially when the slider is full page! a user’s mouse pointer is automatically gonna be positioned somewhere on the page, which than would automatically pause the slider before the user even understands there is a slider function here!
your workaround defeats the purpose, and makes it that the slider cant be interacted with at all.
This is so strange to me. Sliders are incredibly common elements used in web design and to make a gestapo type decision that determines the absolute behavior of an element is a DUMB move.
Of course more options are better than none, but if they’re only giving us a single option then defaulting in this direction is the right move as sliders typically contain content that requires user interaction.
For your use case I’d recommend you look into alternative options with more flexibility like Slick. It’s open source and has tons of options—it’s actually what I use when I work with other platforms. If you have trouble getting it integrated with your project, the community is always here to help
Webflow has thousands of users, how may of them are dedicated web designers by profession?
I believe most of us use Webflow to design 1-2 websites for ourselves, and that is it. We dont tinker with features of a daily basis, we design, upload and forget about it.
As i was about to do the same, it took me 2 days trying to figure out whats happening here. I was sure I was doing something wrong, and it drove me insane. I cleared my browser history 20 times, left forum messages until i came across the explanation.
Now an entire website plan is down the drain because the Webflow team didnt think things through.
I’ve read there was a team meeting where they’ve made that decision and i guess they just didn’t think things through as usual.
Ive been using Webflow for years and one thing ive notices is the “jump first think later” culture that has developed internally within the company. And knowing how this pattern proves itself true time and time again, even if a fix up or a option to choose would take months to implement.
I would really like the team members who are responsible for this to speak up and explain themselves. @PixelGeek@forresto
@mikeyevin
I appreciate the effort you’re putting into justifying this nonsense.
I am not interested in overly complex custom codes, pointless workarounds or anything else for that matter besides what makes sense. OPTIONS.
I came here thinking my slider was broke or I was missing a setting. My slider is 80vh, so I thought it was randomly stopping any time the mouse moved (because the mouse is obviously mostly within the slider.
Nope… just Webflow thinking the one “ah-ha!” accessibility usecase they thought of was the only usecase in existence.
Webflow, please turn “Pause on Hover” into a toggle, not a mandated and hard-wired requirement.
@mikeyevin Negative z-index won’t keep the slide clickable. My entire slide is a link block and each link is different. There’s not a timing issue as you just touch what you want when it shows on screen or use the arrows.
The pause feature needs to be a toggle and not mandated. Non-stop sliding may be terrible UX on your site, but maybe people use tools in different ways so that it isn’t always terrible.
Pause on select (the slide dots) is another story, but still… features are better than requirements.
My intention was never to say that this was the right solution all around, only that I see use cases where not pausing isn’t preferred. This is good UX when using a more “traditional” slider with clickable links however I understand that some folks may have different use cases and prefer the animation to persist. Obviously if I could choose, there would be a toggle to determine the behavior, but unfortunately that doesn’t exist.
The joy of Webflow is that you are always able to lean on custom code to expand or modify native element functionality. @Xel was kind enough to provide a bit of code that overrides the default pause behavior, or you could always implement a completely separate slider component all together like Slick, Glide, or Swiper that may open up more robust functionality.
Hey Xel. I’m pretty much a noob at this. Where exactly do I have to paste this code? Are you referring to the footer section in Project Settings or is this a page setting?
If you need the fix on every page (= you have a slider on every page), put the code into the footer section in Project Settings. But most of the time you just have a slider on one page (Home Page), just put it into the footer section on this page.
