swiper: Responsiveness broken

This is a (multiple allowed):

  • bug

  • enhancement

  • feature-discussion (RFC)

  • Swiper Version: 4.3.5

  • Platform/Target and Browser Versions: macOS 10.12.6 / Safari 11.0.3

  • Live Link or JSFiddle/Codepen or website with isssue: https://github.com/SniperGER/storeUI

To build storeUI, run npm install; npm install -g grunt-cli; grunt build. You can then open the demo in build/demo/index.html.

What you did

storeUI uses a responsive multirow layout with Swiper with 3 rows per group. On screens smaller than or equal 414px (iPhone Plus models), these groups are at 100% width, filling its container. On various iPad screens (9.7", 10.5" 12.9", including portrait and landscape) and above, the slides have a fixed width (10.5" landscape has 384px, while 12.9" portrait has 350px, for example). I’m using the following parameters for a component called “Small Lockup” (3 rows, multiple columns):

roundLengths: 'false', // This should probably be a boolean, but it still seems to work this way
slidesPerView: 'auto',
slidesPerColumn: 3,
slidesPerGroup: 1,
spaceBetween: 32,
breakpoints: {
    414: {
        spaceBetween: 10,
        slidesPerView: 1
    }
    // Various spacing attributes for other screen sizes
    [...]
}

Expected Behavior

Slides should always stay at 3 rows, multiple columns, and should keep their set width. The Swiper container width should not exceed the screen width if using 3 slides or less.

Actual Behavior

On screens smaller than 414px, the sliders are sometimes located beneath each other and the width exceeds the screen width by a thousand. I solved that by using slidesPerView: 1 at 414px. This only happens at iPhone screen sizes, as iPad screen sizes are unaffected. However, setting slidesPerView: 1 breaks the responsiveness of Swiper. Switching between screen sizes (or sometimes even orientations, which is basically the same) results in incorrectly located slides, 1 or 2 slides per row or full width slides as seen on 414px and lower.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 20 (15 by maintainers)

Commits related to this issue

Most upvoted comments

OK, good news, I have a fix and it’s relatively simple. it was because the breakpoints parameters were comming in as strings when in fact they need to be numbers. this was for all the breakpoints parameters that need to be integers not strings. I will push this up as soon as possible, just packaging it up right now.

works great this time!!!