amphtml: amp-carousel: breakpoint specific configuration
Continuing the discussion from #3517: We would like to implement different behavior for amp-carousel
s on different screens. Would it be possible to have the type
property respect media queries aswell?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 27 (17 by maintainers)
We will need to come up with some kind of format to spec the breakpoint config
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.
With the media attribute Layout
Onscroll find next scrollable point (based on a formula - there is already a fn to
getScrollLeftForIndex_
andgetNextSlideIndex_(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
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 formax-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:
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.