Re: [csswg-drafts] [css-pseudo-4] Standardizing input[type="range"] styling (#4410)

> I'd personally recommend going the route of `<selectmenu>` rather than pseudos.

You mean use something like `::part(track) {}` for styling? That's fine with me.

---

As I promised, I'll be going through the problems I've encountered with the current structure/ limitations.

# Problem 1: `track` styles affecting the `thumb`

This happens in WebKit browsers and is due to nesting.

Small refresher: when we look inside the `input[type='range']` in WebKit browsers, we see the following:

![Chrome screenshot of the structure we have inside a range input: the thumb is inside the track.](https://camo.githubusercontent.com/dc3a4508c193efd5107da030af1b9c852023df9c8330c65294387ab6dfea7bb4/68747470733a2f2f692e696d6775722e636f6d2f476c41643455582e706e67)

The Firefox structure is however different:

![Firefox screenshot of the structure we have inside a range input: the thumb is a sibling of the track and progress.](https://user-images.githubusercontent.com/76854602/160802662-8f46a316-7078-48ca-981d-b6fc2f15c741.png)

Now let's consider a slider like the one seen below:

![Screenshot. Shows an example of a track and progress that don't have a (rounded) rectangle shape](https://user-images.githubusercontent.com/76854602/160440002-19c2e135-5392-456b-831f-a64ad67ba919.png)

In this case, the track and progress don't have a rectangular shape. Instead, it's a shape that can be easily achieved with a CSS `mask`.

But this makes the WebKit structure a problem - any `mask` applied on the `::-webkit-slider-runnable-track` pseudo would also affect the `thumb` inside it. That is, it would mask out all the parts of the `thumb` that fall outside the `track` shape. This is not the case in Firefox, where the `thumb` isn't a child of the `track`, but a sibling.

*Side note: we have the same problem if we need to set `clip-path`, `filter`, `opacity` or `mix-blend-mode` on the `track` - all these properties also irreversibly affect the children of the element we set them on.*

Sure, we could make the real `track` a lot bigger, add another `mask` layer that's basically just a disk the size of the `thumb` (specifically for `::-webkit-slider-runnable-track`, it's not needed for the Firefox `::-moz-range-track` and having different selectors means we could set different styles), but there are a couple of big problems with this.

One, the position of this disk needs to get updated whenever the slider value changes, meaning we end up relying on JS for something as basic as just showing the entire `thumb`.

Two, the thumb has a shadow that we lose this way. Making the `thumb` shadow area visible too from the `mask` we apply on the `track` would also show parts of the `track` we don't want to be shown (that was why we masked them out in the first place) underneath the semitransparent shadow of the `thumb`. Setting a `drop-shadow` on the `input[type='range']` would give this shadow to the `track` + `thumb` assembly, not just to the `thumb`.

So in order to reproduce this design with CSS, I had to wrap the `input[type='range']` in a `div` and use the pseudos of this `div` to emulate the non-rectangular parts - well, you can see the [live demo](https://codepen.io/thebabydino/pen/PwaGLM) for yourself.

The illustration below shows what this workaround I've used here looks like when we don't have the `::before` and `::after` of the wrapper and the `input[type='range']` (which has the `thumb` as the only visible part) stacked one on top of the other in the same grid cell, but instead in three different cells.

![Screenshot. Shows the layers of the previous slider. The thumb. The outer non-rectangular area and the inner non-rectangular area](https://user-images.githubusercontent.com/76854602/160865488-1b1d9cd3-dd02-441f-bd03-c707b6f0788c.png)

-- 
GitHub Notification of comment by thebabydino
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1087244943 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 4 April 2022 08:08:58 UTC