[Range] Progressive enhancement as rule of thumb?

[brechtDR]

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

I can't help but thinking that a progressive enhancement idea is going to be tough. I'd love to get some input on this by people with more experience in this field. For me it feels as something polyfillable though.

[myakura]

The tricky part is that <input type="range"> is used to pick a single value constrained by the min, max and step attributes, whereas the newly proposed input is meant to return a range defined by those same attributes. While it’s possible to reuse the min, max, and step attributes, I wonder whether extending the "range" keyword to describe this new input type is the best idea.

[brechtDR]

@myakura I agree with this. In the current explainer, this isn't possible, but I do want to make sure we discussed this as a possibility at least

[sorvell]

I wonder whether extending the "range" keyword to describe this new input type is the best idea.

Is the idea that this would be a new type like multi-range or something?

[brechtDR]

@sorvell To be honest, i'd like to keep the type "range".

The reason for this is that if it works with an extra attribute to opt-in, it might be easier to polyfil and expand? (yes, that's a question, not a statement)

[sorvell]

I wonder if it could make sense as:

<rangegroup name="temperature-range" min=-100 max=100>
  <input type="range" name="temperature-range" min=-50 max=0>
  <input type="range" name="temperature-range" min=0 max=20>
</rangegroup>

Here is an example that, internally, uses 2 ranges in container somewhat like this.

[brechtDR]

@sorvell This idea has passed a few times before but also opens a whole bunch of other questions, such as referencing datalists.

[css-meeting-bot]

The Open UI Community Group just discussed [Range] Progressive enhancement as rule of thumb?, and agreed to the following:

• RESOLVED: Go further with an idea where multiple input type="range" are wrapped inside of a wrapper element. Which wrapper to be further investigated

The full IRC log of that discussion

<hdv> brecht_dr: in the explainer for the enhanced range input, the current idea is to have a `handles` attribute on the range input as we know it today
<hdv> brecht_dr: it'd allow for a number, which specifies how many handles you'd get on the range slider
<hdv> brecht_dr: open questions: should it be a new type? should we have a wrapper, like to group multiple input? do we think it's still possible for this to work in a progressive enhancement kind of way?
<hdv> brecht_dr: I feel we need something that is polyfillable
<hdv> brecht_dr: thoughts?
<masonf> q+
<hdv> ack mason
<hdv> masonf: so question is do we want to reuse input type=range or come up with something new?
<hdv> brecht_dr: yes, where the 'new' thing would be most progressively enhanceable, but not entirely as no multi handle support
<scott-o-bother> q+
<hdv> masonf: I think it'd be difficult to make this progressively enhanceable, so I like the idea of a new element
<sorvell> q+
<masonf> ack scott
<hdv> masonf: but from experience in standards, we may not be able to get that as there's be two things doing the same
<hdv> scott-o-bother: yes historically there were issues with having another element that does something like an existing element
<hdv> scott-o-bother: the only good way to make something like is, is to have two ranges next to each other, and then as you update the current value of range el 1, you'd dynamically need to update min/max/current of range el 2
<hdv> s/like is/like this today
<hdv> scott-o-bother: and keyboard handling would be weird, eg left right arrows on one and what on the other?
<hdv> scott-o-bother: my argument would be that though today we have something, this would be its bigger brother that does more
<brecht_dr> q+
<hdv> masonf: is it two thumbs or n thubms?
<hdv> s/thubms/thumbs
<keithamus> q+
<hdv> brecht_dr: I'd say multi… as people asked as first questions when we talked about having two
<bkardell> q+
<hdv> masonf: is there a use case? of course if we say 2, people will want 3?
<hdv> brecht_dr: gradient generators is one thing that came up
<hdv> brecht_dr: dates… like a flight from till, and another one… probably not great UX but ws an example given
<brecht_dr> q-
<keithamus> q-
<masonf> ack sorvell
<hdv> sorvell: let's discuss multi vs dual in isolation
<hdv> sorvell: I think this use case is different from progressively enhancing <select> … as there is a lot of existing content. With range it's unlikely we'd break a lot of stuff.
<hdv> sorvell: the only sort of viable thing you could do is to show multiple different ranges… but even then there's not a lot of existing conent that'd break
<masonf> ack bkardell
<brecht_dr> q+
<hdv> bkardell: I also think it's its own thing
<hdv> bkardell: I like what Steve put into the issue.
<hdv> bkardell: anything that exists to control a curve, like light dark mid points, lots of things where you control a curve have 3 or more points
<masonf> ack brecht
<keithamus> q+
<hdv> brecht_dr: re the one Steve proposed… if you have an element that wraps existing range sliders, would that be an opportunity to build some kind of fallback?
<sorvell> q+
<hdv> masonf: sounds a lot like what sorvell described. you could future detect
<masonf> ack keith
<hdv> keithamus: I initially thought we should make this an attribute on input, but it complicates input more, and it's already complicated enough, would like to stay away from that
<hdv> keithamus: with multiple input types each can have its own value… having your own element, more than the progressive enhancement case, it also helps answer some other open questions that we have at the moment
<masonf> ack sorvell
<hdv> sorvell: the multiple element idea might also be interesting, because that potentially makes it easier to polyfill
<hdv> sorvell: example in the link I shared
<hdv> sorvell: having its own element would give you an element to hang any custom attributes onto as well
<brecht_dr> q+
<masonf> ack brecht
<scott-o-bother> q+
<hdv> keithamus: you could potentially even get away with CSS if it is its own element
<sorvell> q+
<hdv> brecht_dr: probably should look into this a bit more. Might open some other questions, like for datalist, are we going to work with this kind of pattern too?
<keithamus> q+
<hdv> brecht_dr: only thing I'm kind of scared of is… introducing new elements is tricky, as masonf mentioned at the start.
<masonf> ack scott
<hdv> scott-o-bother: was going to say fieldset before discussion went into multiple elements
<hdv> scott-o-bother: could you potentially have multiple range elements and potentially a new attribute to group them together
<hdv> scott-o-bother: maybe you would instead have like a parent fieldset that also plays into this new conglomorate of widgets?
<masonf> q+
<hdv> scott-o-bother: a fieldset could also have a legend so you'd have a group name and then authors could name each range individually too
<masonf> ack sorvell
<hdv> scott-o-bother: maybe that would be enough for implicit encapsulations, so that browsers could know they belong together
<hdv> sorvell: I think there's a number of options for things like the tick mark
<hdv> s/mark/marks
<hdv> sorvell: eg can only put datalist on it
<hdv> sorvell: or we could get super fancy and have each individual slider define a minmax or a datalist for its own custom tickmarks… could get complex quickly
<masonf> ack keith
<hdv> sorvell: I think generally folks find radio buttons and the way grouping them works, today, somewhat annoying…  but the precedent is there (I don't personally like it)
<hdv> keithamus: datalist can be inside, and this is a historically awkward thing with inputs
<hdv> keithamus: not needing references would be motivation for it
<hdv> s/references/idrefs
<hdv> s/this/that they have to be adjacent
<masonf> ack mason
<scott-o-bother> q+
<hdv> masonf: when I mentioned at the start that new element would be tricky, I was talking about something new for range… re a grouping element, that might be easier, it's a wrapping/grouping element a little bit like <picture> is today
<masonf> ack scott
<hdv> scott-o-bother: I agree, there is a strong enough element for it… and we can point at… these are some very specific accessibility semantics for it
<hdv> scott-o-bother: that we are sure are only for this thing and not for something else
<brecht_dr> q+
<hdv> ack br
<keithamus> q+
<hdv> brecht_dr: for a proposed resolution probably want to go for a wrapper… but also think it's worth investigating scott's idea of a fieldset… that would probably need an attribute though, so may become confusing at some point, but probably worth investigating and not excluding it just yet
<masonf> ack keith
<hdv> keithamus: would push back a little bit on fieldset, as we might have to overload it with a bunch of attributes and overcomplicate it… happy to explore but prefer a new wrapping element
<brecht_dr> proposed resolution: Go further with an idea where multiple input type="range" are wrapped inside of a wrapper element. Which wrapper to be further investigated
<masonf> +1
<hdv> +1
<keithamus> +1
<masonf> RESOLVED: Go further with an idea where multiple input type="range" are wrapped inside of a wrapper element. Which wrapper to be further investigated