[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;
}

[MostafaFawzy7]

@SebastianZ I meant stuff like this:

it would be a circular audio player with a draggable circle for controlling the duration of audio, so I need the runnable tracker of input ['range'] type to be circular...

[LeaVerou]

Wow, thank you @thebabydino for these detailed, wonderfully illustrated posts. This is amazing.

@MostafaFawzy7 Another example of a circular slider is often found in color pickers, for the hue:

(Image source)

However, I’m not sure this kind of styling is in scope for range input styling. I think this will probably still be best left to web components.

---

Standardizing the structure in OpenUI and the pseudo-elements in CSS (or a TF) seems like a good plan forwards. That said, I believe the original thinking behind calling this a "range" input and not just "slider" was that different UAs may want to use different UIs for selecting a number from a range. In practice this has not happened, and all have gone with a slider representation, but theoretically this is still possible. Whatever wording this standardisation effort uses should still allow for innovation in that space.

Logistics-wise, Open UI is currently structured as a CG, right? CGs cannot publish specs. It seems reasonable (and useful) to also have an Open UI WG. Is that something people are interested in?

[jonathantneal]

I’m interested, if we think there are folks to help write and maintain said these works. I think OpenUI can help develop proposals for other working groups to review, @LeaVerou. Could you teach me how, as a WG, this might be different or better? I’ve always been a bit daft to how it all works.

Also... I was just referencing this post for the nth-time for our range/slider/progress/meter type components (because your research, @thebabydino, is so incredibly helpful), and I noticed your latest reply, Lea, is from just a few hours ago. That tells me, maybe this is still an active problem for folks. I’m be so happy to work together toward solutions that help us all.

[MostafaFawzy7]

@LeaVerou Thank you so much for this amazing answer, but let me ask about if this is available as an already based API for input range slider using the circular style?

[thebabydino]

Re: circular sliders (like the one below, which I coded a few years back)

My initial thought was they're not common. While searching for "slider design", I came across just two or three such results, the rest... all classic line sliders! So that seems to be an edge case, and if we take the same path as with selectmenu, a perfect use for having slots where we can replace the track with an SVG circle arc (and can even get a cool 3D look with SVG filters for that).

But then it was pointed out to me that they're rather common in some apps? So perhaps that's a blind spot for me? I don't have a smartphone, I don't use apps, I've relied solely on looking online for interesting designs in order to see what challenges they would pose when it comes to coding them.

So at this point... not sure.

[samuelbradshaw]

My initial thought was they're not common. While searching for "slider design", I came across just two or three such results, … But then it was pointed out to me that they're rather common in some apps?

I think a circular "iPod style" input is easier to use with a touch input device, compared to a mouse or trackpad. That's probably why they're more common in apps than on websites.

[dbaron]

One note about these pseudo-elements: as we're standardizing pseudo-elements like those proposed above (and implementing them), we need to be a little bit careful with their CSS cascading behavior relative to the user agent's styles on the hidden user-agent element that they affect. I think any user-agent styles inside the component should be treated either as an inner context or as from the user-agent origin, so that the pseudo-element overrides this. (I think the two options are distinguishable only in how they interact with other user-agent origin styles and with user styles.)

Historically Blink has treated the user agent's styles in this case as an inner context, with the exception of the style attribute. I ran into this while working on <details> element styling (for which I need to produce an updated proposal at some point soom), and I fixed it for unprefixed pseudo-elements (see background CL 1, backgroundCL 2, and mainly CL 3), but not for the existing prefixed ones, given that I didn't want to figure out the web compatibility implications (which appeared to affect a pretty large number of pseudo-elements, although maybe not the ones in this issue). In other words, the prior Blink behavior treated style attributes in the control (which are often used programatically rather than from markup) differently from style elements in the control. (It wouldn't surprise me if WebKit does the same, although I haven't checked.) I got feedback from the one developer (@bramus) who experimented with my details styling work that the resulting behavior was bad, and thus fixed it as I mentioned (see third CL above), so that style attributes and style elements are treated roughly the same (modulo their existing specified cascading differences).

I realize that we may or may not standardize what the structure and styles of the underlying elements are, but I think it's good if the interaction of any such pseudo-elements with the user agent's control at least behaves according to the CSS model, as though there are underlying elements with styles.

[LeaVerou]

@thebabydino

My initial thought was they're not common. While searching for "slider design", I came across just two or three such results, the rest... all classic line sliders!

This may be a wording confound: I suspect these would not be called sliders by their UI designers, but something else. E.g. "knob" brings up a lot more results, and I'm not even sure it's the established term of art.

[css-meeting-bot]

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

• RESOLVED: Add ::slider-thumb, ::slider-track
• RESOLVED: Define these two pseudos as siblings of each other
• RESOLVED: Apply them to <input type=range>, switch, <progress>, and <meter>
• RESOLVED: Add ::slider-fill when relevant
• RESOLVED: track, fill, thumb are in the same tree order as their usual painting order
• ACTION hober: Add contributors in GH discussion to Acks
• RESOLVED: acknowledge at least thebabydino

The full IRC log of that discussion

<fremy> hober: We have had this issue about range styling for a long time
<fremy> hober: I put it on the agenda because 20 years ago when it was added, we punted the styling
<fremy> hober: mainly because expected appearance to make everything great by default
<fremy> hober: but, every browser implemented their own custom way to style the input, but in different ways
<fremy> hober: both in terms of shadow dom structure, and in terms of what is stylable
<fremy> hober: so, I acknowledge there is a great range of complexity, I don't want to touch all of that
<fremy> hober: people have been digging up how to style them in a cross-browser way
<fremy> hober: it's on emilio to write some spec texts for this, I trust him to do a great job
<fremy> hober: and I'm willing to help with that
<fremy> hober: the reason why I bring this up, because HTML want to add a switch checkbox
<fremy> hober: because it has become very popular on touch UIs
<fremy> hober: and has slightly different semantics
<dbaron> https://github.com/whatwg/html/issues/4180
<fremy> hober: however, one bit is blocking this progressing in HTML
<fremy> hober: the stylability of the control
<fremy> hober: and I noticed switch and range are similar
<fremy> hober: switch is a subset of range, so we can maybe move ahead with the shared part?
<fremy> hober: so, I would love to resolve on making progress on these shared bits first, without blocking this on the differences
<emilio> q+
<TabAtkins> ack TabAtkins
<fremy> hober: the subset of the proposal is ::range-progress, ::range-thumb, ::range-track
<TabAtkins> Also prefer prefixed names, ::slider-* sounds reasonable
<fremy> hober: I guess I would maybe like to unprefix them with "range"
<fremy> hober: so they become more generically applicable
<fremy> hober: all engines implement these pseudos in some way, so that sounds good
<fremy> hober: we could maybe arrange to just alias them?
<fremy> hober: however, this is not as easy, because the structure is different
<fremy> hober: should they be siblings or nested in each other, for instance
<dbaron> hober: In Gecko thumb and track are siblings but in WebKit they have parent-child relationship
<fremy> hober: (webkit nests, other browsers don't)
<fremy> hober: so I thought about this, how to move forward fast?
<fremy> hober: and it seems the flat gecko structure is easier
<fremy> hober: so, I propose we just do that, from the Apple side
<dbaron> hober: for achieving a bunch of the styling use cases
<fremy> hober: and I think that is the only thing we need to do
<fremy> hober: for compat reasons in webkit, there are some concerns, but we are happy to handle it
<miriam> q?
<astearns> q+
<fremy> hober: Apple engineers are willing to sign up to do this work
<miriam> ack emilio
<fremy> hober: for what styles to apply, I trust the judgment of Emilio
<fremy> emilio: A lot of the replaced behaviors are removed if we accept content, for instance
<fremy> emilio: but we can probably define the same behavior with some custom styles
<florian> q+
<fremy> emilio: I'm willing to look into it, I will need to figure those details
<fremy> hober: yes, my goal here is not to solve everything here
<fremy> hober: I hope to solve enough questions for progress to be made
<fremy> hober: we already a resolution I recall to add this pseudos
<fremy> hober: so, my question, if I make a PR for this, would that be agreable to everyone?
<emilio> q+
<fremy> miriam: there is a queue, but can you paste the links to what you showed?
<hober> https://github.com/whatwg/html/issues/4180
<hober> https://github.com/whatwg/html/pull/9546
<fremy> hober: I just paste the html issue
<fremy> and the pull request that is currently blocked
<hober> https://tess.oconnor.cx/2023/08/tracks-and-thumbs
<fremy> and the blog post
<fremy> astearns: is that blog post the explainer fantasai was referring to earlier?
<miriam> ack astearns
<fremy> hober: yes, though now I rephrased a bit better
<miriam> ack florian
<fremy> astearns: so, Blink inherited the webkit structure, right?
<fremy> hober: yes
<fremy> astearns: so Blink engineers probably need to agree as well
<fremy> florian: one thing I wanted to say, is that appearance:none should remove some things, but not what is semantic
<astearns> s/probably need to agree as well/will get the benefit of Webkit figuring out the compat issues/
<fremy> florian: and that should be clarified as well
<fremy> hober: I think if you set it, the pseudos disappear as well, no?
<fremy> emilio: no, they are still stylable, (?) they just have different styles by default (?)
<fremy> florian: that sounds like what appearance would want
<fremy> hober: I'm in favor of speccing what implementations do as much as possible, so we can move fast
<fremy> florian: maybe some are decorative and should go away?
<miriam> ack emilio
<fantasai> Mozilla definitely keeps the pseudos for appearance: none;
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%0A%3Cstyle%3E%0A%3A%3A-moz-range-track%20%7B%20background%3A%20blue%3B%20%7D%0A%3A%3A-moz-range-thumb%20%7B%20background%3A%20fuchsia%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cinput%20type%3Drange%20style%3D%22appearance%3A%20none%22%3E
<fremy> hober: I think they are all semantic
<fremy> emilio: they need to be there, otherwise you cannot restyle them yourselves
<fremy> hober: but you can use pseudo-classes, right?
<fremy> emilio: right
<fremy> hober: for switch, I would like to behave like range
<fremy> emilio: in general, I'm supportive of this
<florian> q+
<miriam> ack fantasai
<fremy> emilio: wrt the bikeshedding aspect, I also agree with the broader naming for reuse
<fremy> fantasai: I also heard a proposal for "slider"
<fremy> fantasai: also, what spec does this go into?
<miriam> ack florian
<fremy> hober: I have an opinion on this, but I'm a bit afraid to open a can of worm
<bramus> FYI: “thebabydino” is Ana Tudor
<fantasai> s/I also heard a proposal for "slider"/I agree with TabAtkins and jensimmons that the names should be prefixed with e.g. ::slider-/
<fantasai> i/fantasai: also/fantasai: Also, whoever drafts this spec should put thebabydino into the Acknowledgements section/
<fremy> florian: there is a holding place somewhere (?) for form-control specific things
<ntim> (I think that's css-ui)
<fremy> hober: I have other plans for the long term, but in the short term that sounds good to me
<fremy> florian: for everything or just a subset?
<florian> s/somewhere (?)/in css-ui-4
<fremy> hober: the whole thing
<miriam> ack dbaron
<fantasai> -> https://www.w3.org/TR/css-ui-4/#control-specific-rules
<fremy> dbaron: I think there are a few interesting things about how much details we need to specify, and how interoperable we need to be
<fremy> dbaron: (1) how the shadow dom is defined
<fremy> dbaron: (2) how the user agent set styles in that shadow dom
<fremy> dbaron: like the position of the range etc...
<fremy> dbaron: this interarcts with the author styles, so we need to say how
<fremy> hober: personally, I would rather not specify the details too much, like what the shadow dom is
<fremy> hober: this is an implementation detail to me
<fremy> hober: if we can't, ok, we should go in this rabbit hole
<fremy> hober: but I would rather not
<fantasai> i/hober: if we/hober: but we can talk about the pseudo-elements and their relationships/
<fremy> hober: for instance, we use the system framework for some things by default
<fremy> hober: and they can be styled a bit
<emilio> q+
<fremy> hober: but probably not everything
<fremy> hober: but I would like to keep that option open for us
<fremy> dbaron: I think you will find it difficult to spec order of things etc in this way in an interoperable way
<miriam> ack emilio
<fremy> emilio: I think the default appearance is not relevant here
<fremy> emilio: because the pseudos only work if you style from a known base
<fantasai> s/default appearance/inheritance/
<fantasai> s/pseudos only work if you style from a known base/pseudos inherit from their originating element, even in shadow DOM/
<fremy> emilio: unless we start allowing ::before/::after, we can probably skip defining the shadow dom
<miriam> ack fantasai
<fremy> emilio: but I agree with media controls, this might be tricker to achieve
<fremy> fantasai: I think one pseudo we also need is the filled part
<TabAtkins> I think that is also minimal set
<dbaron> for what it's worth, emilio, I think we're probably going to want cases where pseudo-elements inherit from each other or from something else in the shadow structure (though not necessarily here)
<fremy> hober: I agree, but this is not required for switch
<fremy> emilio: you can use the pseudo class for switch
<TabAtkins> Not desirable, *required* for range
<fremy> hober: and I'm here to unblock switch
<fremy> fantasai: the other thing we should do is apply the same model to progress and (?) leader
<astearns> s/(?) leader/meter/
<fremy> fantasai: you can style the boundaries differently if you want
<fremy> hober: I'm ok either way
<fantasai> s/if you want/if you want with ::thumb, but default not visible/
<fremy> hober: I want to resolve on adding the pseudo
<TabAtkins> q+
<fremy> hober: and that they apply them to switch, range, etc...
<fremy> hober: I'm looking for a quick consensus
<fremy> hober: can we resolve on them being siblings too?
<fremy> florian: if we have agreement, we might as well resolve?
<miriam> ack. TabAtkins
<miriam> ack TabAtkins
<fremy> TabAtkins: my only comment is that I agree with fantasai that every other element requires the filled part to be stylable
<fremy> TabAtkins: so, I think I want the set of three is required to be truly generic
<florian> q?
<fremy> hober: if we can resolve on that today, I'm fine with it
<fremy> TabAtkins: if we don't do the third one, then we should resolve only about switch
<fremy> florian: what are the challenges for the filled part?
<TabAtkins> s/we should resolve/we are only resolving/
<fremy> hober: I don't remember
<fremy> hober: but EdgeHTML had a few other pseudos
<fremy> hober: but maybe EdgeHTML is not necessary today
<TabAtkins> I'm happy with a "let's handle it ASAP"
<fremy> hober: but which one of the two sides should be stylable etc... I don't know
<fantasai> * Add ::slider-thumb, ::slider-track
<fantasai> * Define them as siblings of each other
<fantasai> * Apply them to <input type=range>, switch, <progress>, and <meter>
<fantasai> * Also add ::slider-fill
<fremy> hober: this might need more research
<fantasai> * Add thebabydino to the Acknowledgements section of whatever spec this goes into
<fremy> emilio: (missed)
<fremy> hober: right now webkit does not have a pseudo for the filled part, but that should be easy to add
<fremy> florian: are they immediate siblings?
<fremy> emilio: not sure if that matters
<fremy> florian: for selector matching
<fremy> fantasai: you cannot see that as an author
<miriam> q?
<TabAtkins> Correct, pseudos don't have an observable relative order.
<fremy> fantasai: with ::marker etc
<fantasai> s/author/author, like ::marker + ::before is not a thing/
<fremy> miriam: fantasai proposed a few resolutions
<fremy> miriam: any opposition to the first one?
<fremy> RESOLVED: Add ::slider-thumb, ::slider-track
<fremy> miriam: the second proposed resolution is to make these elements are sibling of each other
<fremy> miriam: any objection?
<fremy> RESOLVED: Define these pseudosas siblings of each other
<fremy> miriam: third proposal was to apply them to <input type=range>, switch, <progress>, and <meter>
<fremy> emilio: I agree with this one, with an action to investigate the interaction
<fremy> hober: yes, we should
<fremy> miriam: any objection to this?
<fremy> RESOLVED: Apply them to <input type=range>, switch, <progress>, and <meter>
<fremy> miriam: final resolution, we want ::slider-fill
<fremy> miriam: any objection?
<fremy> oriol: counters?
<fremy> hober: in the case of switch, inside the track, there is some text
<fremy> hober: like "on" / "off"
<fremy> hober: so I would like "content" to apply on them
<fremy> emilio: I can read for this, but I don't think there is precedent for this
<fremy> emilio: if we allow counters in the content, order is observable
<fremy> emilio: so the order would be track, fill, thumb from bottom to top
<drott> I'll be right back, but fwiw chris' proposed resolution on #9281 sgtm
<fremy> s/emilio/hober/ for the last sentence
<fremy> fantasai: can we go back to slider-fill and resolve on it?
<fremy> emilio: sounds fine by me
<fremy> RESOLVED: Add ::slider-fill when relevant
<fremy> miriam: and it sounds like we want one more resolution for the ordering of pseudos
<TabAtkins> default paint order, yeah
<fantasai> s/from bottom to top/from bottom to top, not saying anything about tree structure/
<fremy> hober: should we talk about the tree order, or just paining order
<fremy> emilio: let's do tree order
<fremy> miriam: any objection?
<fremy> RESOLVED: track, fill, thumb are in the same tree order as their usual painting order
<fremy> hober: happy to take an action to coordinate
<fremy> hober: if you look at this issue, the extensive research convinced me
<fremy> hober: so we should acknowledge them
<astearns> RESOLVED: acknowledge at least thebabydino
<fantasai> ACTION hober: Add people who contributed to GH discussion to Acks
<chris> q+
<fremy> hober: I will make sure this is the case

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo-4] Standardizing input[type="range"] styling.

The full IRC log of that discussion

<fremy> florian: we resolved too fast
<fremy> florian: the structure we resolved on was not the recommendation in the spec
<ntim> proposed: unresolve on the tree structure for the pseudos
<fremy> fantasai: we didnt' resolve on child relationship
<fremy> fantasai: we resolved the tree order
<fantasai> specifically to avoid resolving on the child relationship

[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. https://github.com/whatwg/html/issues/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 https://github.com/whatwg/html/issues/8413#issuecomment-1326009453

[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: https://github.com/whatwg/html/issues/4177#issuecomment-1882909538

[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 https://github.com/openui/open-ui/issues/959#issuecomment-1866027222

[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 https://github.com/w3c/csswg-drafts/issues/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 https://github.com/w3c/csswg-drafts/issues/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>