amphtml: amp-carousel: breakpoint specific configuration

We will need to come up with some kind of format to spec the breakpoint config

media: {
      'min-width:1024': {
        slidesToShow: 3,
        slidesToScroll: 3
     },
    'max-width:600': {
      slidesToShow: 2,
      slidesToScroll: 2
    }

Navigation The slides work based on the scrolling to the right scrollLeft - in the current scenario if there are 4 slides then the corresponding scroll lefts are (0, slidewidth, 2slidewidth, 3slidewidth)

There are 2 code-paths in the existing code.

• snap points assisted scroll
• • User scrolls - css take over and snaps - update state after a timeout
• javascript assisted animated-scroll
• • User scrolls - JS takes over animation when scrolling stops - animates to destination - updates state exactly after the animation ends

With the media attribute Layout

1. Compute slide width with - total amp-carousel witdth / slidesToShow
2. resize slide containers
3. if possible through JS reset the scroll snap points at the appropriate interval (so that it will scroll to the appropriate scroll left based on slidesToShow and slidesToScroll). For example if slidesToShow is 4, and slidesToScroll is 2 and scrollLeft is 0 - then next scroll left would be , SLIDE_WIDTH * slidesToScroll (will need to tweak this at edgecases like what happens if there are only 2 slides remaining in the end - do we show 4 slides or 2 slides ? ) 4)Right now we only have 3 slides displayed at a time (we hide 2 of them - one on the left and one the right) and this lets us swipe in both directions. no we will have to find the number of slides we need to have hidden

Onscroll find next scrollable point (based on a formula - there is already a fn to getScrollLeftForIndex_ and getNextSlideIndex_(currentScrollLeft) tweaking these functions would basically let us do what we want)

We will also have to figureout what we do when scrolling stops , lets say there are four slides and user scrolled a slide and a half - with the current logic we will snap back to the first slide, but with the new approach since we show multiple slides we could ideally stop at slide 2. This might involve more math but doable

Loops Loops are done using the order property of the flexbox when the carousel is at its last or first slide, now we will have to update order on multiple slides

---

Overall

1. The code could become significantly complex/larger than it already is
2. I anticipate handling snap-points based solution can get significantly hard so we can disable snaps for carousels with media attribute? and always handle it through the JS assisted approach.
3. We might need to version it up
4. Requires extensive regression and testing

Given all these yes we could do this with the existing code without DOM duplication or restructuring

@eike-hass If I understand you right, what you really want is to be able to provide breakpoints for how many slides to show at a time. E.g. it could be 1 slide on max-width:320px, 2 slides for max-width:600px and 3 slides for bigger sizes.

Is this what you want? If that’s the case, I think it’s a very reasonable extension to our current slideshows.

@eike-hass I asked @camelburrito to do a bit of a research into what structure would work for carousel in the next few days. We’ll see what it’d take and how to break it up between us.

Ah, I see, there are essentially two behaviors to support for this request:

1. Support a mechanism that determines the # of slides visible, grouped in a single carousel view
2. Change the # of slides in a group specified by (1), based on breakpoint

Alternately: an option to reduce the bloat without directly supporting (1) and (2) is to allow for slide source argument.

+1 to reducing the bloat somehow. Something like slide source argument seems like a good idea; on the other hand I could see a show-this-many-slides-at-a-time parameter being useful as an option for amp-slides. Regardless of which of these (or another idea) is the right direction, it seems like a good item to roll into the other carousel improvement work (e.g. better visual affordance for number of items in the carousel). Slotting into “Next” for now, but open to feedback and +1s by anyone else in the community looking to support this use-case.

As a side note, there are other component attributes that could benefit from breakpoint dependencies, as well, like amp-sidebar. Just brainstorming here, but if we build support for (1), one idea we could explore for (2) is a generalized way to change attributes based on breakpoints (or other signals—e.g. if we wanted to hook into the binding work somehow), with a whitelist of applicable component/attributes.