[Slider] Control sizing, inset slider design

[vladmoroz]

• We need a prop or a CSS variable to make a slider to work like Radix/macOS slider—Radix and macOS sliders position the Thumb so that its edges are contained within the track (and we always align the Thumb's center to the track edge instead, so it ends up poking out of the Track at the edges)
• minStepsBetweenValues name wasn't too intuitive—will think if there's something better
• Cursor movement is tracked incorrectly when the Control part has padding

Screen.Recording.2024-12-06.at.15.47.26.mov

Not sure what Control sizing has to do anything with the cursor movement; I'd expect it all to be done relative to the Track

Done

• ✅ I expected divs instead of spans, would have saved me a couple situations when my width/height styles wouldn't work right away [Slider] API Tweaks #1017
• ✅ Indicator has position absolute, which makes it harder to style. I don't understand how this is helping me. See this PR for an example. [Slider] API Tweaks #1017
  • ✅ Note: when closing this issue, please make sure that this and this kludge in the demos are removed. [docs] Remove position property from Slider demos #1054
• ✅ Thumb has position absolute, which makes sense. However, if it's positioned absolutely, we need to specify relative to what, otherwise it's a gotcha for the dev to figure out and find the Thumb in a random position on the page first. We need to set position: relative on the Track. [Slider] API Tweaks #1017

Search keywords:

[mj12albert]

I'd expect it all to be done relative to the Track

Movements are actually relative to the Control which is the "tracked area", and the Track is just a dumb component purely for styling the track, because without it you'd have to use a pseudo-element on the Control to style a "visible track" (or insert your own span)... naming issue?

Cursor movement is tracked incorrectly when the Control part has padding

This is probably still a bug, I'll check it out

[vladmoroz]

Movements are actually relative to the Control which is the "tracked area", and the Track is just a dumb component purely for styling the track, because without it you'd have to use a pseudo-element on the Control to style a "visible track" (or insert your own span)... naming issue?

I was explained that Control is the clickable area, so I had used a bit of padding on it (including horizontal) to make clicks and taps easier.

I think no matter what size the Control is, the Thumb would always be placed relative to the visible Track.

In the Anatomy we are also placing Thumb into the Track so altogether that's why I expected it to work this way

[vladmoroz]

I'll remove the horizontal padding from Control in my demo just to be safe for now, but let's still take a note to discuss later whether it's a legit design decision

de8e9ab

[colmtuite]

We need a prop or a CSS variable to make a slider to work like Radix/macOS slider

@vladmoroz "Need" seems a bit strong here? We designed it this way intentionally. When the thumb is contained, the thumb position usually doesn't visually communicate the value accurately, and the pointer becomes misaligned. The current approach seems like a better design?

[vladmoroz]

@colmtuite I'd actually argue that inset thumb has to be the default

the thumb position usually doesn't visually communicate the value accurately

Slider isn't a component for entering precise values anyway, so this doesn't seem like the most important constraint here. Sometimes it's important, sure—I'm well aware of radix-ui/primitives#1966, but precise mapping is more of an edge case for slider in my opinion. It's fine as long as it's going to be an option.

Otherwise, we can't ignore a class of slider designs, like this one:

Centered thumb wouldn't work in UIs like this one too because it would yield a layout collision:

iOS sliders are the same. Because of potential layout collisions and misalignments, I'd almost never want to use a centered thumb—I wouldn't use a slider when a precise value matters anyway.

the pointer becomes misaligned

This has always seemed just like an implementation mistake in Radix. Don't see why it should be misaligned—if thumb has, say, 100px of travel, that should be covered by 100px of pointer travel.

Native range input sliders (which are inset by default) and macOS sliders don't have this issue:

https://jsfiddle.net/1j9x06yu/

---

One more point to consider is that with Radix, it's possible to implement a centered thumb yourself via a 0px thumb element and pseudo elements for the visual thumb, but the reverse doesn't work—you can't implement an inset thumb with the design that we have.

---

Altogether, I think we need something like position: "inset" | "centered" on the Thumb, with inset being the default because it slots into any design layout well and can work with two most common slider design styles—a thin track with a larger thumb, and a thick track and same size thumb.

[colmtuite]

Thumb has position absolute, which makes sense. However, if it's positioned absolutely, we need to specify relative to what, otherwise it's a gotcha for the dev to figure out and find the Thumb in a random position on the page first. We need to set position: relative on the Track.

Yes, if we're setting position: absolute as an inline style, then we must set position: relative as an inline style too. Either we set both inline styles, or leave both up to the user.

Indicator has position absolute, which makes it harder to style. I don't understand how this is helping me.

Hmm right yeah, it's nested inside the track so it just needs a way to handle width