[New Primitive] `Carousel` #3153

chaance · 2021-01-08T22:16:09Z

chaance
Jan 8, 2021
Maintainer

jjenzz · 2021-01-12T20:01:41Z

jjenzz
Jan 12, 2021

0 replies

chaance · 2021-01-12T20:10:23Z

chaance
Jan 12, 2021
Maintainer Author

Great start. Can't believe there's not a slick-carousel on the list here since that's been the one I historically have seen most indie devs reach for despite being unmaintained for years 😅

My biggest concern with drag-to-slide is how it works when composed with other draggable/slideable components composed within the carousel. Are nested carousels supported in any case? What about Slider or audio/video element controls inside of a Carousel? I'm sure we'll get into some funky edge cases here, just something I might consider early if it helps.

0 replies

chaance · 2021-01-12T20:11:53Z

chaance
Jan 12, 2021
Maintainer Author

In the Usain Bolt example, I imagine these slide previews might overflow at certain widths, and they too would become independently draggable. A carousel inside a carousel. 🙃

0 replies

benoitgrelard · 2021-01-12T20:20:59Z

benoitgrelard
Jan 12, 2021

Probably worth adding https://flickity.metafizzy.co/ to the list as well. That's arguably one of the best out there I think.

0 replies

jjenzz · 2021-01-12T20:22:29Z

jjenzz
Jan 12, 2021

Can't believe there's not a slick-carousel on the list here

Your wish is my command 😛

My biggest concern with drag-to-slide is how it works when composed with other draggable/slideable components composed within the carousel

Yeah I was also wondering what sort of media we think should be allowed in these. Are we happy to say they are an open box or would we expose something like SlideImage, SlideDescription to limit the content? 🤔

0 replies

chaance · 2021-01-12T20:55:22Z

chaance
Jan 12, 2021
Maintainer Author

Yeah I was also wondering what sort of media we think should be allowed in these. Are we happy to say they are an open box or would we expose something like SlideImage, SlideDescription to limit the content? 🤔

My thought is that it probably has to be a bit of an open box, but it's potentially problematic even with non-interactive content in ways I haven't considered fully. I'd probably want to still be able to select text with a mouse, for example. I wonder if it would be worth trying to detect the intent of a particular action -- is the user clicking or touching to pressing something, or are they intending to drag? I'd be interested to see how/if React Aria handles this when usePress and useMove are both triggered.

0 replies

colmtuite · 2021-01-13T17:34:11Z

colmtuite
Jan 13, 2021

Some notes after chatting through the discovery with @jjenzz.

The feature list posted above looks solid.

Two things that require further thinking:

We are thinking we could potentially omit the autoplay stuff and loop back around layer to add it on a second pass.
We could maybe have Carousel and a separate GalleryCarousel which re-uses Carousel under the hood but has the more image specific features.

Some notes to clarify particular features:

Prev/Next Buttons

These should be simple, just two buttons.
A somewhat common use case is prev/next buttons which are invisible, but each cover a large area of either side of the carousel (often 25%). The cursor is commonly changed to arrows on hover. This is all just CSS, no need for us to do anything other than provide next/prev buttons.
Another use case is two invisible hover areas, which are not clickable. On hover, they display the button nested inside. This doesn't need to be a component we provide part, the consumer can just add their own random div.

Thumbails
Thumbnails would just be content inside the indicator button. The component would render a button by default, and the consumer just adds content inside.

Decouple events from scrolling
You can set the amount of slides per pane, which are scrolled when you click a next/prev button. However, the touch/swipe/trackpad interaction should not necessarily be tied to this setting.

It works well for image gallery carousels, the kind you see when you click an image in an image grid on Twitter or FB. But there are many cases where you want the touch/swipe/trackpad interactions to function as a normal scroll area, with only the next/prev and indicator buttons sliding a whole pane.

Some research is required here to figure out exactly how best to manage this.

Option to disable swiping on pointer devices
This is something to consider. Instagram and Twitter don't support swiping in their image gallery components. It's arguably a mistake, and I'd vote that it is a mistake.

Indicators
We have identified three different types of indicator element.

Indicator Button would render a <button> by default, and could optionally be rendered as a <div>. Sometimes they indicate the total panes count, others indicate the total slides count. This should be verified by research though, I'm now thinking they only indicate slides when they're progress bars, which would mean we may not need to support both behaviours on this component.
Indicator Count would show the current slide number and the total slides count. Perhaps it should also be able to show the current pane number and the total panes count. Although perhaps it should just work with panes, as per my previous point.
Indicator Progress is commonly seen on social media stories, where each slide has a timer and a progress bar. There is always only one progress bar per slide.

isScrolling state
Expose the state, so consumers can animate/highlight something (like an indicator or scrollbar) while the carousel is scrolling.

Autoplay

Indicator progress bars are dependent on autoplay. If autoplay is not on, progress bars should not render.
We should provide a global interval, for simple carousels.
We also need a custom interval per slide, for story-style carousels.
Pause autoplay on interaction.

Cursor key navigation
Cursor keys should navigate slides, even if there is no focusable content inside the slides. Like an image gallery carousel.

Many carousels have focusable content in each slide. For example, focusable cards on Deliveroo, focusable cards on Netflix, tabs in a carousel on Youtube etc. So we need to ensure that, for example, cursor key navigation still works on tabs, even though each tab would be inside an element like <CarouselItem>.

Nested carousels

For lightbox style carousels, the thumbnails (just indicator buttons) would need to be wrapped in a carousel themselves.

0 replies

benoitgrelard · 2021-01-13T19:52:49Z

benoitgrelard
Jan 13, 2021

I really really like where this is going! ♥️

You can set the amount of slides per pane

There is something interesting related to this in Flickity which I haven't seen many libs support and we haven't mentioned here: variable width cells (ie. images of differents widths/ratios for example).

This is kinda important I would say, and does change the way things will have to be calculated probably (especially around swiping, etc).

Indicators
We have identified three different types of indicator element.

Indicator Button would render a by default, and could optionally be rendered as a
. Sometimes they indicate the total panes count, others indicate the total slides count. This should be verified by research though, I'm now thinking they only indicate slides when they're progress bars, which would mean we may not need to support both behaviours on this component.
Indicator Count would show the current slide number and the total slides count. Perhaps it should also be able to show the current pane number and the total panes count. Although perhaps it should just work with panes, as per my previous point.
Indicator Progress is commonly seen on social media stories, where each slide has a timer and a progress bar. There is always only one progress bar per slide.

I am a little confused by this section, would you mind posting image examples of each things you have in mind for these here?
In my mind, I'm thinking of the little dots, with an active one, but this seems to mention other stuff like number of panes, number of slides, etc which confused me a bit.

0 replies

colmtuite · 2021-01-14T12:23:58Z

colmtuite
Jan 14, 2021

variable width cells

I didn't think of this, so we should probably look into it a little. I see some carousel libs support it, but off the top of my head, I can't think of any valid use cases or any existing examples in the wild. It seems like it would always be a bad design.

but this seems to mention other stuff like number of panes, number of slides,

On Netflix in the screenshot posted above, the indicators reflect the number of panes/pages available, not the number of total slides.

In other carousels, like social media stories (Fleets, IG Stories, FB Stories etc.), the indicators reflect the total number of slides/items.

In both of the cases I've just mentioned, the indicators are not interactive. But often, you would want interactive indicators like the little button dots you mentioned.

0 replies

benoitgrelard · 2021-01-14T13:37:41Z

benoitgrelard
Jan 14, 2021

variable width cells

I didn't think of this, so we should probably look into it a little. I see some carousel libs support it, but off the top of my head, I can't think of any valid use cases or any existing examples in the wild. It seems like it would always be a bad design.

Here's one of the flickity examples: https://codepen.io/desandro/pen/GgQREP
I can definitely see at least this use case for image galleries as you have portrait vs. landscape.

but this seems to mention other stuff like number of panes, number of slides,

On Netflix in the screenshot posted above, the indicators reflect the number of panes/pages available, not the number of total slides.

In other carousels, like social media stories (Fleets, IG Stories, FB Stories etc.), the indicators reflect the total number of slides/items.

In both of the cases I've just mentioned, the indicators are not interactive. But often, you would want interactive indicators like the little button dots you mentioned.

Ah ok I see, I wasn't clear on whether you meant the numbers should actually appear on the page (like 3/5). I see what you're saying now, meaning how many indicators based on if they're indicating slides or panes, gotcha.

0 replies

colmtuite · 2021-01-14T13:41:42Z

colmtuite
Jan 14, 2021

I can definitely see at least this use case for image galleries as you have portrait vs. landscape.

I would file this under "bad design". It's passable in this exact case (the full-width carousel), but still bad. The image should be centered horizontally and vertically inside a fixed-width container.

In a typical image gallery, where you're viewing a single image at a time (the kind on Twitter/IG/FB etc.), this would be very bad. You never want the UI (next/prev buttons etc.) around the image to shift. So the container should always be the same size, and the image is centered inside it.

So at this point, I'd still file this under "not important at all", and potentially even "we should actively discourage this".

0 replies

benoitgrelard · 2021-01-14T13:48:56Z

benoitgrelard
Jan 14, 2021

🤔 I don't see anything shifting on this example. But anyway, just making sure we capture all the things out there.

0 replies

jjenzz · 2021-01-14T19:32:08Z

jjenzz
Jan 14, 2021

This is still very much in DRAFT, but wanted to jot down progress so far in case there are any opinions on this direction so far:

Anatomy

See bullets below for detailed explanation of various bits.

<Carousel  
  as="div"                      // default `div`
  slidesPerPage={2}             // default `auto`
  loop={false}                  // default `true`?
  page={1}                      // default `undefined`
  defaultPage={1}               // default `undefined`
  onPageChange={page => {}}     // default `undefined`
  onScroll={event => {}}        // default `undefined`
  onDragScroll={event => {}}    // default `undefined`
>
  <CarouselSlide as="div" />
  <CarouselSlide as="div" />
  <CarouselSlide as="div" />
  <CarouselSlide as="div" />
  <CarouselSlide as="div" />
  <CarouselSlide as="div" />
  <CarouselSlide 
    as="div" 
    autoFocus                   // Scrolls into view
  />

  {/* non-interactive indicator */}
  <CarouselIndicator as="ol">
    <CarouselIndicatorItem as="li" />
  </CarouselIndicator>

  {/* interactive indicator */}
  <CarouselIndicator as="ol">
    <CarouselIndicatorItem as="li">
      <CarouselIndicatorButton as="a" />
    </CarouselIndicatorItem>
  </CarouselIndicator>

  <CarouselButtonPrevious as="button" />
  <CarouselButtonNext as="button" />
</Carousel>

CarouselIndicatorItem and CarouselIndicatorButton - My thinking here was that the user would render one of these and we would clone it for each page and if they wanted an indicator per slide then they would do slidesPerPage={1}. However, this doesn't cover the case where users might want to put their own content inside. I need to think about this part some more (hence DRAFT). I've been thinking about this (but not hugely keen):

// 1. When there is one slide per page (for thumbnail case usually)
<CarouselIndicator as="ol">
	<CarouselIndicatorItem as="li"><img alt="thumb" /></CarouselIndicatorItem>
	<CarouselIndicatorItem as="li"><img alt="thumb" /></CarouselIndicatorItem>
</CarouselIndicator>

// 2. When you want indicator to clone for you
<CarouselIndicator as="ol">
	<CarouselIndicatorItem as="li" />
</CarouselIndicator>

// 3. When there are multiple slides per page and you want custom content 
//    (this is the one I hate). Do we need this?
<CarouselIndicator as="ol">
	{({ page }) => (
		<CarouselIndicatorItem as="li">{page}</CarouselIndicatorItem>
	)}
</CarouselIndicator>

Perhaps we could stick with 2 for now and then 1 would be part of ImageCarousel (and 3. can do one 😅 )?

CarouselIndicatorButton - Using an anchor tag by default as I plan to get this working without JS as one of our first progressively enhanced SSR components and potentially use aria-current="step" here.
CarouselButtonPrevious and CarouselButtonNext - Prev/next page. If they want to navigate per slide then they would do slidesPerPage={1}. These would only render client-side. Users can scroll until JS kicks in.
slidesPerPage - If auto, a page is considered 100% width of the carousel. To page one slide at a time they can make the carousel the same width as a slide or make slides 100% width and set slidesPerPage to 1.
page - If set to a page that doesn't exist, will show closest page or page % total if looped.
autoFocus - The furthest slide in DOM with this attribute will scroll into view.
onPageChange - Still fires when dragging/scrolling when the page bounds have changed.
onScroll - Any kind of scroll, trackpad or dragging.
onDragScroll - Drag scroll only.

0 replies

chaance · 2021-01-15T02:39:03Z

chaance
Jan 15, 2021
Maintainer Author

A couple of initial thoughts, but otherwise I love the proposed API!

I think it might actually be kind of important to support autoplay. In a11y audits I've seen some implementations where someone used a lib without proper autoplay support and then hacked it by simulating click events, which is ... not great! It's not a super simple thing for a consumer to add later and do it well. Would it really be that much more complexity to include it out of the gate?
Does autoFocus imply that as slides change automatically that the new slide receives focus as it comes into view?

CarouselIndicatorItem and CarouselIndicatorButton - My thinking here was that the user would render one of these and we would clone it for each page and if they wanted an indicator per slide then they would do slidesPerPage={1}. However, this doesn't cover the case where users might want to put their own content inside. I need to think about this part some more (hence DRAFT). I've been thinking about this (but not hugely keen):

Didn't see this as an option in your post, but what about:

<CarouselIndicator as="ol">
  {({ pages }) => pages.map((page) => (
    <CarouselIndicatorItem as="li" key={page.id}>
      <CarouselIndicatorButton as="button" aria-label={page.title}>
        <img alt="" />
      </CarouselIndicatorButton>
    </CarouselIndicatorItem>
  ))}
</CarouselIndicator>

0 replies

jjenzz · 2021-01-15T11:43:34Z

jjenzz
Jan 15, 2021

I think it might actually be kind of important to support autoplay

Yep, I think we're all agreed we need this but as Colm touched on above, we're thinking that could be the second release of this (which we could work on right away if we wanted to). There are features like autoplay that appear to be more suited to image carousels. So, we might just build a separate Slideshow component that would re-compose Carousel and include things like autoplay and arrow key navigation.

When we come to do that work, perhaps we will realise it should just be part of Carousel, which is fine. We're just omitting it now to help save time on those discussions (and the added complexity of doing it well like you say) so we can get an MVP version out there sooner.

Does autoFocus imply that as slides change automatically that the new slide receives focus as it comes into view?

Nope. I'm imagining it much like autoFocus on an input. So, when the Carousel mounts/loads, if a CarouselSlide has autoFocus it will gain focus and scrollIntoView. I added this because the consumer won't necessarily know what page a particular slide is on so they can't just do defaultPage={3}. Pages could be dependent on viewport dimensions. That's why I also added this:

onPageChange - Still fires when dragging/scrolling when the page bounds have changed.

So, if they have page={2} but also have autoFocus on a slide that isn't on page 2, it would scroll into view and call the onPageChange callback 👍

Didn't see this as an option in your post, but what about

That is the same as my proposal I believe except I meant we would do the map under the hood for them. I think I confused the situation by rendering page in the item. That wasn't meant to be a component, it's just the page number. The focus of the proposal was the function as child thing tho like yours:

<CarouselIndicator>
	{({ page }: { page: number }) => (
		<CarouselIndicatorItem>
      		<CarouselIndicatorButton>
				Page {page}
			</CarouselIndicatorButton>
		</CarouselIndicatorItem>
	)}
</CarouselIndicator>

There is no page data object here, only what page number the indicator is trying to render an item for.

I'm just not sure if this pattern is worth it for our first release. This is the sort of thing I'd prefer to pass on personally until we understand how people are using it and it is specifically requested for something that cannot be achieved without it. I'm struggling to think of genuine use-cases that 1 and 2 don't already cover. Can anyone else?

0 replies

hananint · 2023-07-10T11:03:56Z

hananint
Jul 10, 2023

Looking forward to this. Any updates, please?

0 replies

Vintotan · 2023-07-13T17:49:05Z

Vintotan
Jul 13, 2023

I don't understand why this carousel component was not integrated into the radix-ui primitive, as it is already used on the radix-ui.com website 🤔

There is already an existing component: https://github.com/radix-ui/website/blob/main/components/marketing/Carousel.tsx

0 replies

FleetAdmiralJakob · 2023-07-14T11:59:36Z

FleetAdmiralJakob
Jul 14, 2023

@Vintotan That's weird

0 replies

jjenzz · 2023-08-02T09:35:49Z

jjenzz
Aug 2, 2023

@Vintotan tmk, the version on the website is an incomplete version of the accessible carousel we were building that supports the website's specific use-case. carousels come with some complex a11y requirements that we never got around to finishing (especially if it is to be customisable) hence why it was not added to radix yet.

0 replies

CodeNinjaMatrix · 2023-09-16T07:43:37Z

CodeNinjaMatrix
Sep 16, 2023

@Vintotan tmk, the version on the website is an incomplete version of the accessible carousel we were building that supports the website's specific use-case. carousels come with some complex a11y requirements that we never got around to finishing (especially if it is to be customisable) hence why it was not added to radix yet.

Can we have a simple version that not so customizable first, then optimize later? Is that anything we can help?

0 replies

decafboba · 2023-10-10T14:56:21Z

decafboba
Oct 10, 2023

@jjenzz Do you have any update for this? We would really love to see it implemented!

0 replies

kungfu321 · 2023-10-28T14:16:09Z

kungfu321
Oct 28, 2023

Any update on this issue :)

0 replies

jasonaravanis · 2023-10-30T04:32:55Z

jasonaravanis
Oct 30, 2023

Also interested in this being added to Radix!

0 replies

peiris · 2023-10-30T11:35:05Z

peiris
Oct 30, 2023

Pretty please, give us a carousel primitive 🥺🙏🏼

0 replies

decafboba · 2023-11-23T15:14:18Z

decafboba
Nov 23, 2023

@jjenzz Is this something that will be developed, or should we assume any progress has been paused for the rest of the year? Our team needs to know if we need to begin searching outside of the Radix UI primitives for this, or if we can hold off until this is out.

We'd love to hear an update form your end 🙏

0 replies

callumflack · 2023-11-23T23:16:19Z

callumflack
Nov 23, 2023

I don't think carousels are needed in Radix. Carousels are not a primitive. So I can understand why they don't want to do it. (Also, Radix has no responsibility to your team needing to know anything).

Carousels should be used with care, designers always seem to do the old "can we just…" dance with them, and they get complex quickly. KISS approach with a working 1st version is best.

Instead, use this simple typescript hook with CSS scroll-snap and get it to done.

0 replies

FleetAdmiralJakob · 2023-11-24T11:54:55Z

FleetAdmiralJakob
Nov 24, 2023

And in the new Radix UI components that are prestyled?

0 replies

decafboba · 2023-11-26T23:21:42Z

decafboba
Nov 26, 2023

I don't think carousels are needed in Radix. Carousels are not a primitive. So I can understand why they don't want to do it.

What is and is not a primitive is subjective. Plenty of the "primitives" in Radix are not direct HTML element wrappers like . Most UI libraries offer a Carousel because of how frequently that are needed.

(Also, Radix has no responsibility to your team needing to know anything).

If they have no plans on implementing this, then they should state so and close this issue. Otherwise, teams are being delayed.

0 replies

lucasgelfond · 2024-05-05T14:29:05Z

lucasgelfond
May 5, 2024

Bumping this up—I'd way rather use a Radix native carousel than grab from react-responsive-carousel! Another point in favor (although obviously — maintainers may have a reason, etc) is that shadcn (essentially Radix + Tailwind) has its own Carousel component! https://ui.shadcn.com/docs/components/carousel

Will probably use theirs, but makes it messy because I am anti-tailwind / prefer vanilla Radix. What do maintainers think about this? Busy for a bit / wouldn't be for the next few weeks, but if maintainers are open to this I'd be happy to take a crack at adapting Shadcn's carousel back to radix standards and getting a PR up

0 replies

howells · 2024-05-05T14:38:49Z

howells
May 5, 2024

@lucasgelfond bear in mind that shadcn's solution is just Embla. I just ended up using Embla, skipping shadcn, when I faced the same problem, and works well.

0 replies

[New Primitive] Carousel #3153

chaance Jan 8, 2021 Maintainer

Replies: 52 comments

Carousel Research

Real world examples

Google cast

Netflix

Instagram

Squarespace

Usain Bolt

Mercedes Benz

Toyota

Lib examples

Bootstrap

React carousel

Slick

Flickity

React Responsive Carousel

Comprehensive features

Questions

chaance Jan 12, 2021 Maintainer Author

chaance Jan 12, 2021 Maintainer Author

chaance Jan 12, 2021 Maintainer Author

Anatomy

chaance Jan 15, 2021 Maintainer Author

[New Primitive] `Carousel` #3153

chaance
Jan 8, 2021
Maintainer

chaance
Jan 12, 2021
Maintainer Author

chaance
Jan 12, 2021
Maintainer Author

chaance
Jan 12, 2021
Maintainer Author

chaance
Jan 15, 2021
Maintainer Author