Should we standardize the anatomy of `<input type=range>`?

[mfreed7]

First, I'm a bit unclear on Open-UI vs. WhatWG HTML for this. This issue is about standardizing the pseudo element parts of the Web Platform <input type=range>. Does this belong here? Or in WHATWG? I do see that there is a research page for "slider" which is the Open UI concept implemented by <input type=range>.

Problem

1. No healthy way to style the filled/progress amount of the slider
   1. CSS only solutions are bound to the size of the track based on the only cross browser solution possible
      1. example from native-ui (about as beautiful as they get)
      2. example: since this design called for the thumb to be larger than the track, CSS only can't show the "filled" amount
   2. current prefixed selectors stomp each other, so developers are forced to duplicate styles
      1. Josh Comeau sharing their learnings about this oddity: tweet
   3. Javascript solution runs on page load and watches for user input to update a custom property
      1. example
   4. Firefox has ::-moz-range-progress
      1. MDN
   5. we've recently added support for accent-color which will tint this fill range state, but still can't target it with a selector and give it a gradient background
2. Partial support of

Tasks:

1. Separate track from progress and enable ::-webkit-slider-progress-track as a style target for CSS
2. Complete current ticks implementation to work with vertical
   1. unprefix the selectors
   2. support attribute
3. Add labels to our slider implementation
4. Help spec a way to style the labels and ticks

Resources

• Range ticks/hashes/labels: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range#A_range_control_with_hash_marks
• HTML 5.1 spec: https://www.w3.org/TR/html51/sec-forms.html#range-state-typerange

--> Full credit due here to @argyleink

[una]

1000% agree we need standardization on this. Thanks for opening this, @mfreed7

[gregwhitworth]

@mfreed7 I've started the work on this in the past: https://open-ui.org/components/slider.research.parts

Also, I outlined to @emilio what the next steps are here because Firefox wants this standardized too: https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-783022435

[gregwhitworth]

@mfreed7 @emilio circling back on this as @una and I were just discussing this issue. Is the primary goal here to solely standardize the named parts? Because that can be done quickly - there will still be a LOT of interop styling issues without going further but that would at least remove the need for numerous prefixed props.

[mfreed7]

Thanks for the pointer to https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-783022435, I had seen that but hadn't read it in detail. I'm in favor of trying to do what you lay out in that comment - i.e. try to really "fix" the <input type=range>, not just do the quick fix. Assuming there's appetite to keep the full specification moving, and it sounds like there is, let's do that.

You can likely close this issue in favor of continuing with https://github.com/w3c/csswg-drafts/issues/4410.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[bkardell]

So, @thebabydino is going to be doing some focus on this. She's given more thought to these problems and tried to do more with ranges than pretty much anyone else I can think of, so that's quite good news for openui, imo. It would be great if we could help direct her on the pragmatic way forward. She's shared a number of comments on the linked issue already https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1086891786. I'm not sure if assembling these all into an explainer (she'd like to not use md, I think) is best or setting right into fleshing out the pages that exist in open ui for 'sliders', or...? Maybe we can discuss on the call this week

[css-meeting-bot]

The Open UI Community Group just discussed Should we standardize the anatomy of <input type=range>? #297.

The full IRC log of that discussion

<hdv> topic: Should we standardize the anatomy of <input type=range>? #297
<hdv> github: https://github.com/openui/open-ui/issues/297
<hdv> bkardell_: in the research we found a couple of things, some map to HTML components, like sliders that are currently fairly well mapped to input type=range
<hdv> bkardell_: this topic was raised by masonf, to discuss whether we should standardise the anatomy of input type=range
<hdv> bkardell_: the person who has been doing a lot of codepens and tutorials and blog posts around this is Ana Tudor
<hdv> bkardell_: the CSSWG made one minor decision, but said anything in terms of specifying anatonomy and doing interesting new things should be done in Open UI
<hdv> s/anatonomy/anatomy
<hdv> bkardell_: Ana got some funding to work on this and we were wondering how to best handle this
<hdv> bkardell_: we would like to get to a point where we can share a well thought out proposal to start, probably an explainer would be the right thing to do? what do you all think?
<masonf> q?
<scotto__> q+
<hdv> JonathanNeal: I was reviewing code today where a developer had styled input=range… and I maybe gave them the wrong advice
<masonf> q+
<hdv> bkardell_: it looks like it could go a similar route as select, maybe improvements to input type=range or even a new element, is a bit premature to say now
<hdv> bkardell_: would like to hear from someone who might end up reviewing this
<masonf> q?
<hdv> emilio: apart from coming up with a consistent model for this, we probably need to assess the impact from changing it
<jhey> type=rangemenu :D
<hdv> bkardell_: I think the plan would be to research that and have it all in one place
<hdv> bkardell_: I wanted to find out if that makes sense to people
<hdv> emilio: it makes sense to me
<hdv> JonathanNeal: would you like to spin up a new issue for this or get comments on the current issue?
<hdv> bkardell_: let's spin up a new issue and let her attach to that
<jhey> New element type with slots for the thumb, track, bar and ability to read the value in CSS.
<JonathanNeal> jhey, no more input types. i mean it. :P
<jhey> :D
<hdv> JonathanNeal: I would support that too
<hdv> bkardell_: ok I;ll open a new issue when we have an explainer
<hdv> bkardell_: we could resolve to begin an explainer with Ana and myself as the editors
<JonathanNeal> q?
<masonf> q-
<JonathanNeal> ack scotto__
<hdv> scotto__: I think an explainer makes the most sense at this point… I don't even know… can the current element even have its anatomy redone to be more consistent across browsers without breaking what people had to do to get consistent behavior across browsers?
<jhey> Still waiting for slidey sliders and circular ones JonathanNeal :D https://twitter.com/jh3yy/status/1546970773222572032
<hdv> bkardell_: it's really hard to style across browsers now… it breaks already between demos now
<hdv> masonf: it is also confusing to be that we have progress and meter elements and also input type=range
<hdv> scotto__: semantics
<tantek> +1 to the confusion across progress, meter, range etc.
<JonathanNeal> q?
<JonathanNeal> as the author of ye olde postcss-input-range package, I don’t know what you mean... : sweat emoji :
<hdv> bkardell_: do we just do a PR to the website? as we have proposals and explainers there?
<hdv> JonathanNeal: makes sense to me, does anyone have other information they want to add?
<hdv> Zakim, end meeting
<Zakim> As of this point the attendees have been vmpstr, dandclark, JonathanNeal, chrishtr, scotto__, flackr, emilio, una, bkardell_, hdv, masonf, vmpstr>, dbaron, tantek
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/08/25-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, hdv; please remember to excuse RRSAgent. Goodbye

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[lukewarlow]

Is there anything I can do to help move this along I notice there's research but not an anatomy still. I'm happy to contribute and help come up with an exhaustive anatomy. Might need someone to explain the exact mechanics behind the anatomies.

For example with the below anatomy should progress and thumb (ignoring the names) be inside of track? And should the slot be inside of part or should it wrap it? Select has slots wrap parts but file for example has parts wrap slot?

<AnatomyWrapper>
      <Host name="openui-slider">
        <Part name="track">
          <Slot name="track" />
        </Part>
        <Part name="progress">
          <Slot name="progress" />
        </Part>
        <Part name="thumb">
          <Slot name="thumb" />
        </Part>
      </Host>
    </AnatomyWrapper>

[thebabydino]

Just commenting to say that, in light of the data I collected from the recent CodePen challenge, I've changed my mind about the anatomy I had in mind prior to this. To exactly what, it's not even clear to me. Every solution comes with its own set of problems.

What I can say is this: if the progress or thumb are inside the track, they will be affected by filter effects, clipping, masking on the track.

For example, we may want to have a filter creating a 3D effect on the track. Let's say we want our track to look like below:

We can get this effect with an SVG filter (CodePen live example), but this is also going to affect all descendants - this is why putting the progress and the thumb feels like a bad idea.

Another example would be the case where we want to have a mask on the track, but the thumb should be bigger and expand outside the area retained by the mask:

However, the track, the progress and the thumb are siblings in the current Firefox implementation and this comes with major disadvantages too.

[lukewarlow]

https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1720875895 it seems the CSSWG resolved on some standard pseudos. It would be good for us to ensure they meet the requirements we've found

[lukewarlow]

From a quick glance it seems the main issue with the CSSWG resolved structure for range is that it doesn't support multiple thumbs. How big of a deal do we think that is?

[mfreed7]

That'd be good to comment on. Seems important, since many of the examples given in that issue describe multiple thumbs.

[gregwhitworth]

From a quick glance it seems the main issue with the CSSWG resolved structure for range is that it doesn't support multiple thumbs. How big of a deal do we think that is?

I agree that this would be the item that I'd bring up. We don't have psuedo-element short-hands so we can't make slider-thumb a shorthand for slider-thumb-one and 'slide-thumb-two`.

I will note that I'm personally ok with slider-thumb being the name for slider-thumb-two (or whatever it's called) because most browsers don't implement this and so it would increase complexity. They could of course implement slider-thumb-one without slider-thumb-two but that would make it weird for devs to have a name that indicates there should be more than one and it not be available.

[emilio]

I wouldn't like to block ::slider-thumb on a potential ::slider-thumb(n) / ::slider-thumb-two or so pseudo... It seems we could implement multiple thumbs in the future if needed. cc @hober, fyi.

[lukewarlow]

Yeah I'm not sure it's required to block just something to be aware of to ensure shipping these doesn't preclude it down the line.

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

Moved the question to the csswg issue https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1722028412

[yisibl]

CSSWG doesn't seem to consider multiple thumbs, where do we need to move it forward?

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.