SwiperJs adds a class, that alowes styling for the pagination and swiper-buttons if the swiper is currently “locked” - meaning there are not enough items inside the slider for the current viewpor so that the interactive elements don’t serve a purpose.
From the CSS it seems that the original idea was that bricks tries to set the buttons to display:none, but this doesn’t work, since the button has a display:flex!important in it’s initial setup.
we can override this with the @layer bricks.reset utility layer, but I just figured you might want to look into this, since it looks like an unintended behaviour.
Edit: this is a custom Bricks Element, but this issue is present in all native bricks elements aswell, since I’m useing the bricks-swiper styles and script
thanks for reaching out. I can see this locally as well, but I’m not sure if this was unintended behavior or not.
Just to make sure I understand the issue or the problem you are facing correctly, let’s say I add Carousel element, choose 4 images, but set 6 to show. At that moment, you don’t want arrows to be visible, right? As far as I see, they are just transparent a bit.
SwiperJs has very finely tuned utility classes it adds, depending on the current state of the Slider.
The opacity change you mentioned is present because of the .swiper-button-disabled class.
This class gets added/removed from any of the navigation buttons, depending on if you can interact with it or not.
So if you have a looping Slider it would never be disabled, but if you have a regular slider and you are at the first slide, the prev-button will be disabled and vice versa on the last slide the next-button will be disabled.
This is in contrast to the .swiper-button-lock class, which allows styling for the interactive elements, if they don’t serve any purpose at all for the current viewport.
E.g. the pagination with one dot and buttons that are always none-interactable are unnecessary, and swiper allowes style them accordingly (e.g. display:none).
You’re almost correct in your understanding, but if you look closly at the screenshot, you will see that the .swiper-button-lock “tries” to hide the buttons when they don’t serve any purpose and the opacity is a byproduct of the .swiper-button-disabled class.
A permanantly none-interactable element (lock) is also always a temporary none-interactable element (disabled)
I know this isn’t the biggest issue, and thanks to the @layer bricks-reset support we as users can circumvent this issue, but I thought I just bring it up, since it doesn’t seem intentional. Otherwise I will just add it to my personal reset.
thank you so much for your answer. I have to confess that I never dig deeper inside the Swiper.js, so I wanted a confirmation, which I got, so thank you.
I’ve created an internal task and I think we should fix that.
Ideally, like I said before, we shouldn’t have an important statement in our cascade layers.
I also wholheartetly support the notion that the default bricks styles shouldn’t have any ! important statements, but if for any reason your Team thinks otherwise, consider this “trick”:
This brings the “benefit” of no other source, can override the display property by accident, but any developer worth their salt, has easy access to modify the property with a low specifitcity selector.
I would never remember to implement it this way. Not only in Bricks, but also for personal projects.