[css-pseudo-4] Standardizing input[type="range"] styling

[richiksc]

Currently, the state of styling <input type="range"> across browsers is a nightmare. Chrome, IE, Safari, and Edge each have their own way of styling range inputs with differently named pseudo-elements. With this proposal, I want to bring some unity and standardization to this similar to the CSS scrollbars spec. Currently, Chrome has no support for styling the "progress" part of a range input (the area corresponding to "below" the current value, in LTR languages, the track to the left. @danielstern has written an article about it on CSS-Tricks, and although it was last updated in 2017, most of it still applies.

Definitions

Thumb: the UI element that the user interacts with and is dragged by the user - it shows the current state of the range.
Track: The "groove" or bar that the thumb runs along - shows the "range" (min and max values) of the range.

Current state of range styling

WebKit/Blink (Chrome/Opera/Safari):

::-webkit-slider-thumb { /* Styles the thumb of the input*/ }
::-webkit-slider-runnable-track { /* Styles the track of the input*/ }

Firefox

::-moz-range-thumb { /* Styles the thumb of the input*/ }
::-moz-range-track { /* Styles the track of the input*/ }
::-moz-range-progress { /* Styles the progress/fill below the thumb of the input*/ }

IE/Edge

::-ms-thumb { /* Styles the thumb of the input*/ }
::-ms-track { /* Styles the track of the input*/ }
::-ms-fill-lower { /* Styles the progress/fill below the thumb */ }
::-ms-fill-upper { /* Styles the fill above the thumb */ }

Proposal

As you can see, attempting to style a consistent range input across browsers is a daunting task and requires a lot of CSS and repetition of styles. I'd like to propose three new standard pseudo-elements for styling the range:

::range-thumb { /* Styles the thumb of the input*/ }
::range-track { /* Styles the track of the input*/ }
::range-progress { /* Styles the progress/fill below the thumb of the input*/ }

Sample CSS for the above mockup would be something like this:

input[type=range]::range-track {
  width: 100%;
  height: 20px;
  border-radius: 10px;
  background-color: #eee;
  border: 2px solid #ccc;
}

input[type=range]::range-thumb {
  width: 40px;
  height: 40px;
  border-radius: 100%;
  background-color: white;
  border: 2px solid #1976D2;
  box-shadow: 0 0 5px rgba(0, 0, 0, 0.25);
}

input[type=range]::range-progress {
  height: 20px;
  border-radius: 10px 0 0 10px;
  background-color: #2196F3;
  border: 2px solid #1976D2;
}

[rchrdnsh]

man, i just found out that this has not already existed since 2003...is this even close to existing?

[rchrdnsh]

this could change the world for web based audio and video players, no?

[rchrdnsh]

Could we say ::range-control or ::range:handle as opposed to ::range-thumb, as this feels like a very specific(to english?) and awkward choice?

I could imagine people from other languages then english finding that very odd, no?

[richiksc]

@rchrdnsh However, thumb is the term that browsers have already been using. I think it is the official technical term for it as well.

[rchrdnsh]

hmmmm...could we not...just...change it? I'm not all that concerned about official terms if official terms aren't so great...but I'm willing to be persuaded if there are any materials that could logically support the use of the word 'thumb'. But ultimately if it's something that can not be changed for historical or technical reasons, then ok. But if we just added control or handle, and then let thumb live a long and natural life, then when it was no longer used we simply removed it...could that kind of thing be possible?

[gnat]

This would be amazing to make standard! control / track is also a great suggestion for intuitiveness. Keeping thumb would be a mistake unless there's a good reason for it; I also found thumb to be confusing at first (I am a native English speaker).

That said, either is better than this remaining non-standard.

[dfvalero]

what can we do to move this?

[richiksc]

@dfvalero, yeah, I'd love to push this forward.

[richiksc]

@fantasai Is it possible to flag this for WG discussion?

[emilio]

I've added this to the agenda to discuss it. I think the proposal is reasonable, but given it matches Gecko, it may be interesting what other implementors think about it.

There's a few details about which properties apply to these pseudo-elements which may be interesting to flesh out too. For example Firefox's UA style has these !important declarations which other engines may or may not have.

cc @mfreed7

[gregwhitworth]

Similar to how we handled the file input I would like for this to be uniform with the Open UI effort which itself is trying to holistically define form control parts outside of psuedo elements themselves. Additionally, not only across UAs but what common patterns exist across component libs, OS, etc. The range control itself can take on many forms outside of what is currently implemented by UAs. I get the desire for a short term solution but I would like to ensure that we're not designing ourselves into a corner. I hadn't seen this or else I would have had someone tackle the research in Open UI for range already.

[gnat]

Let's not lose sight this is a simple story about a minor iteration to just standardise what has already been in place for a long long time.

It would be sad if this was shelved in the hope of a full redo- that would warrant an entirely different discussion.

[gregwhitworth]

@gnat that's why this line is the important part to focus on in my comment:

I get the desire for a short term solution but I would like to ensure that we're not designing ourselves into a corner.

I'm not opposed to solving this as I wasn't opposed to the file control discussion more that we should ensure that we're not designing ourselves into a corner.

[gregwhitworth]

Ok, had a little bit of time to sit down and update the Slider analysis on Open UI. The concepts across libs can be seen here.

But more importantly, I dug into each for the part concepts they support and the subsequent naming of these sub-parts. The table rendered below can be seen here.

Based on this, specific to your proposal I am thumb and track win out across almost all endpoints. progress not so much but there isn't much agreement here across the industry it seems but there is agreement that this is needed, even though a few don't currently ship with this supported.

A few that I'll propose for the Open UI anatomy will be number output, content start/end, marks, steps, mark content and probably tooltip. So basically for now I'll avoid two handles. That said nothing in the above will block this.

We may want to consider marks, steps and mark content as these are actually already standardized - some UAs render them and others don't but they aren't reachable. To scope to this I think I'll just give my support to the current proposal and create a new one for those others to bring interop on the prefixed ones.

[dfvalero]

Hi @gregwhitworth, I think that there is no option to style the "Filled Selected Track" for webkit browsers

[richiksc]

@dfvalero

Hi @gregwhitworth, I think that there is no option to style the "Filled Selected Track" for webkit browsers

A 'filled selected track' has been present in the range control for Chromium-based browsers since Chrome 81.

https://blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html?m=1

[dfvalero]

Hi @gregwhitworth,

Yep but, as far as i know, there is no way to style it :'(

[gregwhitworth]

@dfvalero @richiksc that is why there is no name for it but the concept does exist. That's why I broke them apart. The fact that the concept exists in the UA but doesn't have access shouldn't be overlooked. That's why I wanted this research. We should also ensure that the tick marks and values work as well which currently is spec'd but not supported and should be reasoned about while we discuss these psuedo's.

[gregwhitworth]

Oh, one thing that we haven't discussed is the limitations on styling of those psuedo elements. I haven't done that research - @richiksc any chance you did that across the UAs because that will need to be defined as well.

[richiksc]

@gregwhitworth I haven't done any research on that yet, but I can work on it.

[gregwhitworth]

@richiksc the best way I've found is to iterate over all dom APIs on the prototype chain for a given el under .style and apply potential values based on type and then check if that was applied since you can access these psuedos. My gut instinct is any layout/positioning props outside of display: none will not apply. So you'd primarily be looking at color modifications. It would be good likewise to understand if transition or animations work on various ones.

[richiksc]

@gregwhitworth Sorry, could you explain that further? As far as I know, you can't access a pseudo-element from JavaScript, so there's no way to iterate over its .style attribute.

Edit: In addition, we are only discussing modern/evergreen browsers, right? So effectively I'd only have to test Webkit/Blink (Chrome, Opera, Safari, Edge, Safari iOS, Samsung Internet) and Gecko (Firefox)?

[gregwhitworth]

@richiksc ahh, valid point - my apologies wrote that up in haste, historically I did it on DOM nodes themselves. Seems like we'll need to do this the old fashioned way then. As noted above, I'd test the following as a good start for manual testing or we can spelunk in the code to determine which props they don't allow.

• layout props (width, height, display: inline, flex, grid, none, margin, padding, border, box sizing, etc)
• position props (top, left, bottom, right, position)
• decorative (background, color, box-shadow, etc)
• animations (transitions, animation)

[emilio]

Regarding properties, we only used to restrict a couple ones. https://bugzilla.mozilla.org/show_bug.cgi?id=1663819 is related here.

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo-4] Standardizing input[type="range"] styling, and agreed to the following:

• RESOLVED: Continue working on standardizing these 3 pseudos

The full IRC log of that discussion

<dael> Topic: [css-pseudo-4] Standardizing input[type="range"] styling
<dael> github: https://github.com//issues/4410
<dael> gregwhitworth: I can try and take if it the person isn't on the call
<dael> emilio: These people rpoposed standardizing a model similar to Gecko. Subtle differences. Added to get feedback. Modal is fairly simple. Could go one way or other. Would like to hear from WK and Blink if it's interesting to using more Gecko-like model and if there's interest in standardizing.
<gregwhitworth> q+
<astearns> ack gregwhitworth
<fantasai> Proposal:
<fantasai> ::range-thumb { /* Styles the thumb of the input*/ }
<fantasai> ::range-track { /* Styles the track of the input*/ }
<fantasai> ::range-progress { /* Styles the progress/fill below the thumb of the input*/ }
<dael> gregwhitworth: To get more specific the proposal is 3 different items. Range-thumb, range-check, and reange-progress. Concrete is missing
<dael> gregwhitworth: did a decent amount of research b/c I was hesitant we'd design into a corner. These 3 are unanimous. I'm in favor of standardizing. Would need concrete what can/can't they do analysis.
<dael> iank_: From blink, I don't know if mason is on. Quick look this is interesting. Would welcome improvement. I don't think we have concept of progress element, but could be wrong. Agree with gregwhitworth and analysis of what properties would/wouldn't be respected would pave way for easier implementation
<dael> gregwhitworth: I will note WK you have a concept of tracking. I don't know if you have an element.
<dael> iank_: I don't believe we have an element.
<dael> gregwhitworth: Okay, okay
<dael> iank_: Just purely a paint effect I believe
<smfr> q+
<jensimmons> q+
<dael> gregwhitworth: I had requested the research. We can action me and I'll reping the person to know what's interop so we cna get a concrete proposal
<dael> iank_: Sounds great
<astearns> ack smfr
<dael> smfr: WK has html progress which is pre-fork. Certainly interested in participating in standardizing
<jensimmons> q-
<dael> smfr: the range pseudo elements
<dael> astearns: Sounds like we have consensus to work in this area
<dael> ACTION gregwhitworth respond to commentor on #4410 to see if they can do the research
<dael> gregwhitworth: Yep. smfr if you can see what you limit that would be great. I'll compare with Maz in Chromium
<jensimmons> q+
<dael> iank_: We recently did a bit of work to simplify in this area so may be pretty different to WK
<florian> I wonder if we're painting ourselves into a corner, and excluding alternative designs (dial like, or other things)
<dael> gregwhitworth: Got it. I'll definitely test
<astearns> ack jensimmons
<gregwhitworth> q+
<emilio> q+
<dael> jensimmons: I want to advocate for a holistic way to get at these problems. Similar space to other conversations. Jumping to we should make pseudo elements. We should look at the whole system, not just this one control. gregwhitworth I think said this in the thread. Terrific we're doing this, but should look at whole thing and not just design separately
<dael> leaverou: Agree with jensimmons. We standardize pseudo elements on a piece by peice basis. There was proposal for parts to standardize. What happened to it? Why create different pseudo elements when can make one for all form controls.
<astearns> ack gregwhitworth
<tantek> +1 jensimmons, take a look at the whole system
<una> +1 jensimmons and leaverou as well -- forms need wholistic review
<dael> gregwhitworth: I really do think and maybe there's an OpenUI joint meeting that makes sense, I don't want to paint into a corner. OpenUI is holistic appraoch. There's 3 or 4 topics where we talk in meta and go in circles while we do ad hocs. But I don't disagree with accent color and these where it technicallye xists
<dael> gregwhitworth: We should do the holistic thing but web is the web today. There are valid use cases not supported in UAs that should be documented.
<dael> gregwhitworth: I'll throw together and ad hoc agenda for joint meeting with OpenUI. There's 3 or 4 topics we could cover. There's enough overlap between the groups. I'm in favor of resolving on these 3 elements but it won't allow you to go to the extent of content swapping
<dael> gregwhitworth: Also point to explainer that Google, Edge, and Salesforce did which is put together a model definition. I think that's worth exploring in joint meeting. Get opinions on that model because does allow part access instead of one offs
<astearns> ack emilio
<dael> emilio: I think gregwhitworth had good points. I agree to finding a holistic solution is useful and needs to pursue. This is standardizing reality. The prefixed pseudo elements won't go away. Allowing authors to not write same style in 3 selector lists is good
<dael> astearns: Agree we should consider holistically and happy to see peoplelike gregwhitworth and Mason are doing the research.
<dael> astearns: It seems like we are doing the holisitic consideration. If there are gaps in the analysis it would be great to raise those in the issues
<florian> Doesn't seem that these pseudos would let you do this sort range controls (or style a UA that had them): https://cdn.shopify.com/s/files/1/0017/2972/products/PX5-chromcapsprodcutpage_580x387.jpg?v=1596119507
<dael> astearns: For this issue we have the next step of figure out what things could be used on these pseudos.
<dael> astearns: Should resolve we do want to make progress on the proposed range pseudos
<dael> astearns: Prop: Continue working on standardizing these 3 pseudos
<dael> astearns: Objections?
<dael> RESOLVED: Continue working on standardizing these 3 pseudos
<dael> astearns: Where it goes, I'm assuming pseudo spec?
<dael> fantasai: Yes or do we want a spec of form controls and their pseudo elements?
<dael> astearns: Yes, does make some sense to have form control pseudos by themselves
<dael> gregwhitworth: We could add that for discussion at joint meeting. I would love to not duplicate. If they're just pseudo elements they go in pseudo. If we spin up a form control spec it goes same patch as OpenUI.
<dael> astearns: That okay fantasai ?
<dael> fantasai: Okay. If we end up adding lots that's specific to a form control at that point it should move to its own spec. Currently mostly specific to page
<dael> gregwhitworth: That's what I was trying to take away from is that overlap. Pseudo elements are a part but ultimately define an anatomy. If we go that route do we spin a new spec for parts? This can be in holistic discussion about where things live. this is part of Open UI anatomy discussion

[lukewarlow]

Various element structures (not sure how much is web exposed)

Blink:

<progress>
   <::-webkit-progress-inner-element>
      <::-webkit-progress-bar>
         <::-webkit-progress-value />
      </>
   </>
</progress>

<meter>
   <::-webkit-meter-inner-element>
      <::-webkit-meter-bar>
         <::-webkit-meter-even-less-good-value />
         or
         <::-webkit-meter-suboptimum-value />
         or
         <::-webkit-meter-optimum-value />
      </>
   </>
</meter>

<input type="range">
   <::-webkit-slider-container>
      <::-webkit-slider-runnable-track>
         <::-webkit-slider-thumb />
      </>
   </>
</input>

WebKit:

<progress>
   <::-webkit-progress-inner-element>
      <::-webkit-progress-bar>
         <::-webkit-progress-value />
      </>
   </>
</progress>

<meter>
   <::-webkit-meter-inner-element>
      <::-webkit-meter-bar>
         <::-webkit-meter-suboptimum-value />
      </>
   </>
</meter>

<input type="range">
   <::-webkit-slider-container>
      <::-webkit-slider-runnable-track>
         <::-webkit-slider-thumb />
      </>
   </>
</input>

Firefox:

<progress>
   <::-moz-progress-bar />
</progress>

:-moz-meter-sub-sub-optimum::-moz-meter-bar
or
:-moz-meter-sub-optimum::-moz-meter-bar
or
:-moz-meter-optimum::-moz-meter-bar

<meter>
   <::-moz-meter-bar />
</progress>

<input type="range">
   <::-moz-range-track />
   <::-moz-range-progress />
   <::-moz-range-thumb />
</input>

I can see it was resolved to apply these to input[type=range], meter and progress. I can I think work out the intention for range inputs

I interpret the below to be the new structure.

<input type="range">
   <::slider-track />
   <::slider-fill />
   <::slider-thumb />
</input>

The intention for the others is less clear to me?

Would it simply translate to the below?

<meter>
   <::slider-track />
   <::slider-fill />
</meter>

<progress>
   <::slider-track />
   <::slider-fill />
</progress>

[emilio]

We didn't resolve on all-siblings vs. track as a parent of fill and a prev sibling of thumb. But other than that, yeah.

[yisibl]

And don't forget the ::-webkit-resizer in <textarea>, which I had a proposal for many years ago.

https://lists.w3.org/Archives/Public/public-html-ig-zh/2013Jun/0029.html

[yisibl]

On many pages, the range input also displays the current value, should we add a new pseudo-element for this?

IE used to have a ::-ms-tooltip, which provides us with a reference, so standardizing ::tooltip(csswg#8930 ) in CSS would be the way forward. @LeaVerou

See also: https://css-tricks.com/sliding-nightmare-understanding-range-input/#aa-tooltip-current-value-display

[yisibl]

There is an angle picker in Chrome DevTools, which requires some ticks, pointers for style, and shortcuts like Shift + click for interaction.

• https://codepen.io/ademilter/pen/DqBJNZ
  

[nt1m]

There is an angle picker in Chrome DevTools, which requires some ticks, pointers for style, and shortcuts like Shift + click for interaction.

I think this type of UI would require more than just CSS pseudo elements, you'd need to somehow make dragging work. All browser engines currently assume dragging is always in a single axis.

[yisibl]

I think this type of UI would require more than just CSS pseudo elements, you'd need to somehow make dragging work. All browser engines currently assume dragging is always in a single axis.

Yes, I also think it's too complicated to add it to the range input, maybe this needs a new HTML element for that.

[yisibl]

@lukewarlow The range input in Edge will have more pseudo-elements that you can update to your reply.

::-ms-fill-lower 
::-ms-fill-upper
::-ms-ticks-before
::-ms-ticks-after
::-ms-thumb
::-ms-track
::ms-tooltip

[LeaVerou]

And don't forget the ::-webkit-resizer in <textarea>, which I had a proposal for many years ago.

That’s not as simple, because I believe the triangular resizing UI is not part of the spec, so you'd want to allow different UIs like horizontal or vertical dividers.

Though then again, no harm in having a pseudo for the triangular resizer which simply doesn't exist in these cases.

[yisibl]

Consideration also needs to be given to introducing a new property to control the direction of the progress bar.
whatwg/html#4177

[yisibl]

And don't forget the ::-webkit-resizer in <textarea>, which I had a proposal for many years ago.

That’s not as simple, because I believe the triangular resizing UI is not part of the spec, so you'd want to allow different UIs like horizontal or vertical dividers.

Though then again, no harm in having a pseudo for the triangular resizer which simply doesn't exist in these cases.

Yes, I admit that the ::resizer issue is a bit more complicated and this should be opened as a separate issue.

[mfreed7]

Consideration also needs to be given to introducing a new property to control the direction of the progress bar. whatwg/html#4177

This can just be direction… see whatwg/html#8413 (comment)

[yisibl]

Consideration also needs to be given to introducing a new property to control the direction of the progress bar. whatwg/html#4177

This can just be direction… see whatwg/html#8413 (comment)

@mfreed7 Only direction cannot be made to display vertically. See: whatwg/html#4177 (comment)

[annevk]

I think the idea of separately controlling orientation of a control from writing-mode/direction has merit, but it needs its own issue. It's more widely applicable than <input type=range> after all. It would make controls even more complex as then you will need to account for writing-mode being X, but orientation being Y, but it might not be insurmountable now the code to account for writing-mode has been added.

[LeaVerou]

Controlling the orientation of the slider through writing-mode is a hack, as writing-mode is intended for linguistic control, and that's in many cases a presentational decision in UIs with non-vertical writing modes.

[yisibl]

In addition, we need to clarify whether these pseudo-elements should support the content property. See openui/open-ui#959 (comment)

[mfreed7]

I think the idea of separately controlling orientation of a control from writing-mode/direction has merit, but it needs its own issue. It's more widely applicable than <input type=range> after all. It would make controls even more complex as then you will need to account for writing-mode being X, but orientation being Y, but it might not be insurmountable now the code to account for writing-mode has been added.

Given the comments, I've filed #9832 to discuss the orientation/direction question.

[lukewarlow]

Has there been any further discussion on the anatomy of a range input given these new ::track and ::thumb (assuming #9830) and ::fill (::slider-fill?) pseudos?

As far as I understand there's still the issue that WebKit (and blink) differ from Gecko's arrangment of the track, thumb, and fill?

[jacobrask]

We've been able to implement every component so far in our new CSS based design system using CSS only. Range styling was the first major roadblock where we couldn't accomplish an accessible design across browsers without resorting to JavaScript.

This looks like a great and simple proposal to me, getting it standardised and implemented would allow the removal of a lot of poor workarounds across the web.

<input type="range">
   <::slider-track />
   <::slider-fill />
   <::slider-thumb />
</input>