[Range] Handle count and maximum limitations?

[brechtDR]

Based on explainer: https://open-ui.org/components/enhanced-range-input.explainer/

We need to decide whether to support more than two handles in range inputs, and if so, what the maximum limit should be?

What I would like to resolve in this issue:

• Should we limit support to dual-handle ranges only, or allow for more handles?
  • What are the use cases that justify more than two handles?
• If supporting more than two handles, what is a reasonable maximum limit?
• Any first accessibility implications of multiple handles vs dual?

[sorvell]

What are the use cases that justify more than two handles?

• gradient stops
• bezier curve stops
• date ranges with preference windows for start and end

If supporting more than two handles, what is a reasonable maximum limit?

Maybe < total steps?

Any first accessibility implications of multiple handles vs dual?

I think handles should be tab navigated and 2 or N seems no different.

[thebabydino]

Re the linked structure: it has the thumbs inside the track. Having the thumb inside the track is one of the most problematic things about the current WebKit structure because it means we cannot apply properties like filter or mask to the track without them affecting the thumb. This is extremely problematic when we want to have a mask for a non-rectangular track shape, but the thumb is bigger. Also when applying a lighting filter to give the track a 3D aspect.

Same goes for the ticks. Definitely not inside the track.

[lukewarlow]

Fwiw per CSS forms as it currently is we have the thumb as a sibling to the track.

I think there's an issue somewhere related to updating the OpenUI names, we should also match the structure as well.

See https://drafts.csswg.org/css-forms/#slider-pseudos

Relevant issue #1197

[css-meeting-bot]

The Open UI Community Group just discussed [Range] Handle count and maximum limitations?, and agreed to the following:

• RESOLVED: Go for multi-handles because of the use-case. The maximum is author's choice. Create a separate issue for the potential accessibility problems such as tabbing through a huge amount of thumbs

The full IRC log of that discussion

<sorvell> q+
<masonf> q+
<hdv> brecht_dr: main question here is: do we want to handle more than 2 handles, and if so is there a maximum?
<masonf> ack sorvell
<hdv> brecht_dr: and what would be the accessibility implications of multiple handles?
<hdv> sorvell: I'm in favour of multiple handles. You don't see many more than 2, but for two you see a lot. Price range is the obvious one
<hdv> sorvell: I reviewed a number of them and they are all very custom. Only one I found used input type=ragne
<hdv> s/type=ragne/type=range
<keithamus> q?
<keithamus> q+
<hdv> sorvell: it's uncommon, and you almost never see more than 2, that's even more uncommon. It's a niche, but we might cover it while we're at it
<scott-o-bother> q+
<frehner> q+
<masonf> ack mason
<masonf> ack keith
<hdv> masonf: there are use cases for three… part of my fear around having multiple was how to handle the different values… a wrapping element seems to solve that nicely. So +1 to multiple, even more than 2
<sorvell> q+
<hdv> keithamus: the colour stops example is compelling. There are use cases where you want to stop range slides from overlappping other ones… but in the case of colour stops, most UIs allow you to it, it's an array… but certain things, like a price range, the range is 'exclusive'.
<hdv> keithamus: for some price range situations, you might have multiple exclusive ranges
<masonf> q+
<brecht_dr> q+
<hdv> keithamus: there's a lot of nuance around which ranges are exclusive, and how do you overlap …so might this potentially become a giant can of worms?
<masonf> ack scott
<hdv> keithamus: maybe we could support to a certain extent and say folks are on their own outside of that
<hdv> scott-o-bother: things to consider re accessibility… in many cases you might be more interested in the middle value rather than the min or max. You're using the range not to go to 0 or 100 but in between
<hdv> scott-o-bother: so re exposing we probably would want to expose the middle number
<hdv> scott-o-bother: does that introduce maybe that we have to introduce a new way of exposing the value?
<hdv> scott-o-bother: another thing I was thinking about… even with multiple range inputs in a wrapping container… what is the general idea of how that would initially look? would it be like hey there's a bunch of inputs next to each other? or would the browser do something smart, like make it 'one track' via the UA styling?
<hdv> scott-o-bother: will we need new keyboard patterns for this? I don't have an answer but would be good to discuss and consider more
<masonf> ack frehner
<hdv> frehner: when there is a singular track with multiple ranges on it, how would you be able to target each?
<hdv> brecht_dr: this would be handled inside of the explainer with something called segment styling.
<masonf> ack sorvell
<hdv> brecht_dr: will especially be great for color stops use case
<hdv> sorvell: what about the limit to number of thumbs?
<hdv> sorvell: probably wouldn't make sense to have more thumbs than steps?
<hdv> sorvell: probably want a relationship to the steps
<keithamus> q+
<hdv> sorvell: btw I do agree there is a big can of worms going from 1 to 2… not sure if there's another from 2 to n, may have already covered it in 1 to 2
<hdv> s/can/jar
<hdv> s/jar/can
<hdv> masonf: when you have n… practically speaking from visual point of view, you want to paint the segment differently between the two, so it's a rendering issue
<hdv> masonf: how would we style n+1 segments?
<hdv> masonf: the wrapping element is the thing that is rendered, will the actual range elements also be in DOM and styleable? lots of open questions. Whatever the approach, it should be fully styleable. That won't be straightforward
<masonf> ack mason
<masonf> ack brecht
<sorvell> q+
<hdv> brecht_dr: keith mentioned 2 different ranges working together… could we add another wrapping element to wrap multiple ranges that belong together? might complicate things even more though
<masonf> ack keith
<masonf> q+
<hdv> keithamus: I think that's totally viable… was compelled by Mason's point that it's a rendering issue
<hdv> keithamus: if you think of this as two different sides… the first is what do you submit as the form data, a list of names and list of values, the second is the UX
<masonf> q-
<masonf> q+
<hdv> keithamus: re multiple exclusives and different names and that it is a styling issue… I kind of feel that sorvell's is right that the bigger can of worms is going from 1 to 2 rather than 2 to n
<brecht_dr> q+
<hdv> keithamus: I think re amount of steps vs number of ranges… I think HTML should try and recover from those situations as well as it can, like it does with other things
<masonf> ack sorvell
<hdv> sorvell: I think we're probably all with the grouping element, and imagining the think we're grouping is input type ranges… that's a choice, it could also be another element, like subrange
<hdv> sorvell: one of the values of multiple elements is that you could have multiple things to hang attributes on, like attributes to be used to specify names so you could group by common names
<masonf> ack
<hdv> sorvell: could also give us better styling options
<hdv> masonf: re grouping slides together with attributes… does seem very niche, we want to make sure the super special case is possible but not should make the simple case harder to grasp 
<hdv> masonf: and imo we probably don't want to limit the numbers of ranges or steps
<sorvell> Multiple exclusive ranges: date range flexibility: start dates v. end dates.
<masonf> ack mason
<masonf> ack brecht
<hdv> brecht_dr: I'm more in favour of styling on the wrapper element, for author simplicity… is something we have in customisable select as well
<hdv> brecht_dr: from what I'm hearing now, the maximum amount of thumbs could be author responsibility
<hdv> brecht_dr: you can create bad UX patterns today with divs
<keithamus> q+
<masonf> ack keith
<hdv> keithamus: with validation it can get pretty wild; when it comes to DOM there's a lot one can do, like hide inputs, take ones away, adjust values outside of validations
<hdv> keithamus: the gradient one is a classic example where you can add a new stop… requires more thought for the developer but that's probably fine
<brecht_dr> q+
<masonf> ack brecht
<hdv> keithamus: I think it's fine if the simple use cases work in HTML and the more complex ones require author to write some JS
<hdv> brecht_dr: seems viable to me. Person who authors a fancy gradient color stop thingy could probably just add a maximum in their script for their users
<bkardell> max of 2147483647
<brecht_dr> proposed resolution: Go for multi-handly because of the use-case. The maximum is author
<sorvell> q+
<brecht_dr> proposed resolution: Go for multi-handly because of the use-case. The maximum is author's choice. Create a separate issue for the potential accessibility problems such as tabbing through a huge amount of tabs
<masonf> ack sorvell
<hdv> sorvell: I think tab makes sense to jump between ranges
<brecht_dr> roposed resolution: Go for multi-handles because of the use-case. The maximum is author's choice. Create a separate issue for the potential accessibility problems such as tabbing through a huge amount of tabs
<brecht_dr> Proposed resolution: Go for multi-handles because of the use-case. The maximum is author's choice. Create a separate issue for the potential accessibility problems such as tabbing through a huge amount of tabs
<sorvell> +1
<masonf> +1
<bkardell> +1
<brecht_dr> Proposed resolution: Go for multi-handles because of the use-case. The maximum is author's choice. Create a separate issue for the potential accessibility problems such as tabbing through a huge amount of thumbs
<hdv> +1
<keithamus> +1
<brecht_dr> RESOLVED: Go for multi-handles because of the use-case. The maximum is author's choice. Create a separate issue for the potential accessibility problems such as tabbing through a huge amount of thumbs

[meyerweb]

What are the use cases that justify more than two handles?

The preferred departure time for my flight is 9:30am, but I’m open to flights that leave after 6am or before 3pm. A three-handle slider would make that relatively straightforward to express. Similarly, “show me all items that cost between these two price points, but prioritize those around this point” or even “prioritize those between these two other price points between the first two”.

I’ll also second the gradient-stop and bezier-curve examples. I could also imagine using them in interfaces like audio processing and filtering applications.