Add a new part(s) or element(s) for customizing navigation buttons

[jpierson-at-riis]

Clear and concise description of the problem

As a developer using Swiper element I want to have a simpler way to override the icon and visualization of the included navigation buttons so that I do not have to create custom next and previous buttons.

Suggested solution

Introduce a new part or set of two parts to the parts supported for Swiper Element.

Single part for both:

• navigation-svg

or

Two separate parts:

• button-prev-svg
• button-next-svg

Alternative

Pseudo selectors and attribute selectors on existing parts

Alternative approaches attempted do not suffice apparently due to how ::part works.

/* Attempt using attribute selector */
swiper-container::part(button-prev)[aria-disabled=true],
swiper-container::part(button-next)[aria-disabled=true] {
  display: none;
}

/* Attempt using attribute selector */
swiper-container::part(button-prev).swiper-button-disabled,
swiper-container::part(button-next).swiper-button-disabled {
  display: none;
}

Additional custom elements for navigation buttons

Another alternative solution could be to introduce separate child elements <swiper-button-prev> and <swiper-button-next> which could be similar to how <swiper-slide> works in that the developer can provide their own implementations as children of the swiper-component element in order to provide the markup for the buttons to be used. While this may be the more extensible and elegant option I'm not sure of the limitations of web components myself and whether it is possible to have multiple custom components as children in the same what that swiper-slide currently works so my preferred proposal would be to expose the additional parts for overriding styles as a simpler initial approach.

Additional context

See discussion linked below. There are at least five examples that I've come across so far of developers running into the limits of what can be done with the built in Navigation CSS properties and the Navigation button parts and I think that improving this area of the component will help to reduce how much custom code is needed when adopting Swiper in many cases.

#4348

Validations

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Would you like to open a PR for this feature?

• I'm willing to open a PR

[nolimits4web]

What is wrong with

• adding custom navigation buttons
• using inject style parameter

Even with these extra parts it won’t cover all necessary use cases

[jpierson-at-riis]

@nolimits4web, I wouldn't say that anything is wrong with these approaches but what I'm noticing is that in a particular application that I'm upgrading from an old version that used jQuery to now use the Swiper element is that almost every instance of swiper-container has custom navigation buttons which are different for each. In total so far I have four different sets of custom navigation buttons. One of these I was able to customize by hiding the stock svg and supply the icon for the button via an image referenced through CSS but the others require a custom set of navigation elements. It would be nice if there was a more consistent model for customizing the navigation buttons without having to resort to different strategies depending on the customization at hand especially when the customization is about the appearance of the button and and not necessarily where it is positioned.

The main issue that I have with the custom button approach is positioning. Once you have custom elements for navigation buttons then the developer is on the hook to position these elements as well as to style them completely when all they may wanted to do is to provide a different svg or other content or simply change some of the basic appearance of the button in a way that is not exposed through the limited set of custom style properties. Additionally, what I'm finding is that so far I've been able to implement all necessary customizations as CSS or HTML and have not needed to do anything beyond calling the register() function. In order to accomplish something simple such as hiding the nav buttons when disabled, I'm finding that I will either need to recreate the rules for layout and positioning of custom nav buttons or write additional javascript to inject styles when it would be nice if this seemingly common need could be accomplished declaratively in either HTML or CSS if the right extensibility points are provided.

After working further with Swiper and tweaking the project to behave exactly like the old jQuery version I'm wondering if a slot could be introduced for the navigation buttons as a way of providing an extensibility point? The concept of slots seems to work well for the the container-start and container-end slots as a way of providing a way of injecting elements into the layout of the component. Perhaps a navigation-button-prev and navigation-button-next slot could be introduced to inject custom content that would be rendered as the child of the buttons?