[Feature Request] Multi-Thumb Slider

[jdelight]

How might we update Lion's input range component to add support for selecting a range as well as what it currently does (selecting a value within a given range). Similar to the examples here under "Ranged" https://material-components.github.io/material-web/demos/slider/

Essentially we need to allow users to select a min and max value within a single component (as opposed to having two single value sliders).

However, looking at the Material Design example above, it appears to effectively render two sliders, overlayed and with their min/max attributes dynamically defined. So the start range max is clamped to the end range current value, and the end range min is clamped to the start range current value.

Also appears there are some WAI ARIA guidelines and examples for this component too:

• https://www.w3.org/TR/wai-aria-practices-1.1/#slidertwothumb
• https://www.w3.org/TR/wai-aria-practices-1.1/examples/slider/multithumb-slider.html

[gerjanvangeest]

To have two overlaying sliders (<input type="range">) would make sense indeed, and then use the aria- attributes as you shared.

I like the names of material "mwc-slider" and "mwc-slider-range", but since we already have "input-range", we should think of a good name for the double handles component.

On a technical note, i guess it should be a fieldset with two input fields.

The public API would be something like:

<lion-input-range-group
  label="Amount"
  name="amount"
  min="0"
  max="500"
  .modelValue=${{low: "30", high: "100"}}
></lion-input-range-group>

[jdelight]

Thanks @gerjanvangeest that all makes sense. First quick attempt shown below. Just want to get a sense of if this is broadly heading in the right direction or if I've misunderstood the approach you've suggested (regarding using Fieldset). Initially I attempted to extend LionFieldset but that seemed complicated and the examples I can see all render the lion-fieldset component as opposed to extend it.

/* eslint-disable import/no-extraneous-dependencies */
import { html, LitElement, ScopedElementsMixin } from '@lion/core';
import { LionFieldset } from '@lion/fieldset';
import { LionInputRange } from './LionInputRange';

/**
 * @typedef {import('@lion/core').CSSResult} CSSResult
 */

/**
 * LionInputRangeGroup: extension of lion-input-range.
 *
 * @customElement `lion-input-range-group`
 */
export class LionInputRangeGroup extends ScopedElementsMixin(LitElement) {
  static get scopedElements() {
    return {
      'lion-fieldset': LionFieldset,
      'lion-input-range': LionInputRange,
    };
  }

  // eslint-disable-next-line class-methods-use-this
  render() {
    return html`
      <lion-fieldset name='inputRangeGroup' label='Input Range'>
        <lion-input-range
          name='low'
          min='0'
          max='100'
          .modelValue='${50}'
          unit='%'
        ></lion-input-range>

        <lion-input-range
          name='high'
          min='0'
          max='100'
          .modelValue='${50}'
          unit='%'
        ></lion-input-range>
        <button @click='${ev => console.log(ev.target.parentNode.modelValue)}'>
          Log to Action Logger
        </button>
      </lion-fieldset>
    `;
  }
}

modelValue is defined as the object {low: [int], high: [int]} as expected here.

Of course the this class will need to accept similar attributes to a range input and mirror those to both underlying inputs, handling validation on ranges etc...

[gerjanvangeest]

The LionFieldset is indeed a bit too much, we could use the FormGroupMixin, which bridges all the functionality of the child form controls: ValidateMixin, InteractionStateMixin, FormatMixin, FormControlMixin etc.

And then both inputs should be placed in the light-dom, so they are accessible for screen-readers. @tlouisse do you have a simple example available of this?

[tlouisse]

Hi, sorry for the late response.
My best guess would be to implement it as a LionField, with a multi thumb slider as interactive element/_inputNode.
See:

• https://www.w3.org/TR/wai-aria-practices-1.1/examples/slider/multithumb-slider.html
• https://dequeuniversity.com/library/aria/slider-multirange
• https://lion-web.netlify.app/guides/how-to/create-a-custom-field/

[tlouisse]

Thanks for the proof of concept @jdelight! I l like the idea of having a modelValue that accounts for bot the high and low value. Also nice job on the functional styling.

The thought of a group makes sense since we have two tab stops, but as seen in the examples above (deque and w3c) we don't need the [role=group] for accessibility.
But maybe [role=group] still would be a valuable addition in case of two tab stops (other example of where we have two tab stops and not a group is the datepicker)... any thoughts @erikkroes ?

Putting elements in light dom can make sense for the following reasons:

1. a11y: we want to give them their own error messages/descriptions/labels that our parents (fieldsets) can reference to. In case of fieldset children (or checkbox/radio children) this makes sense.
2. they need to be considered individually approachable inputs. The two sliders can be given separate names (name=myLowSlider and name=myHighSlider) and can be controlled by an Application Developer individually.
3. I'm not sure on this one, but if you add [role=group] around a set of inputs... will the sr only announce them once in light dom? Would need to be tested on all sr combis...

I think both 1 and 2 would not apply here. 3 would only apply if we would need [role=group].

As to the approach chosen in the poc:

• We usually try to avoid composition inside our own FormControls (it's more expensive since you need to bootstrap three instead of one components with a complex prototype, so an extension of LionInputRange (or Fieldset)) makes more sense.
• the element with the modelValue needs to inherit from FormControl, so it has all registration logic, interaction states, validation behavior etc etc. => you can test your component in umbrella-from in form-integrations package.

So most likely we would need to go for smth like :

approach 1

• extend the LionInputRange:

export class LionInputRangeMulti extends LionInputRange {
  /** @protected */
  _inputGroupInputTemplate() {
    return html`
      <div class="input-group__input">
          <!-- this will be thumb-low -->
        <slot name="input"></slot>
        <slot name="thumb-high"></slot>
        ${!this.noMinMaxLabels
          ? html`
              <div class="input-range__limits">
                <span>${formatNumber(this.min)}</span>
                <span>${formatNumber(this.max)}</span>
              </div>
            `
          : ''}
      </div>
    `;
  }
}

• you most likely need to add all aria-labelledby and aria-describedby to the second thumb as well, see: aria-describedby and aria-labelledby connected to _inputNode (thumb1). You need to override this method (or make it protected and more generic so that it accepts an array) and include [slot=thumb-high] as well.
• if we need [role=group] (likely not), we could apply it to the host (LionInputRangeMulti), so that our screen knows about the fact that we're grouping two controls

approach 2

If you experience trouble having two inputs (this is gonna be challenging) you can consider a small webcomponent wrapper for the two inputs that serves as your _inputNode, just like in https://lion-web.netlify.app/guides/how-to/create-a-custom-field/

Update: I would definitely go for the distinct web component that would be a proxy for the two thumbs. Depending on our a11y needs, we could make it render to either light dom or shadow dom. See the example on https://webcomponents.dev/edit/g6P3uxthQKz3klHVTX3T/src/index.js?p=stories

[tlouisse]

I will try to make a small example on webcomponents.dev to illustrate it a bit better when I have the time :)

[tlouisse]

@jdelight
I wrote a demo for approach 2: https://webcomponents.dev/edit/g6P3uxthQKz3klHVTX3T/src/index.js?p=stories

Note that:

• it uses the slider logic of w3c example for _inputNode to allow me to quickly create this demo. Feel free to consider using two native input[type=range] instead like you did in your poc. (I think we should go for the solution with best a11y and 'stylability')
• it uses shadow dom for _inputNode. This should work fine, unless screen reader testing would prove otherwise.

I hope this can serve as a start :)
It would be highly welcome if you could elaborate on this :)

• write test suites as described by Gerjan on Slack
• test it for a11y on all browsers => consider whether the 'native approach' is not better
• rewrite the logic copied from w3c, make it our own and apply as a controller
• consider extending from LionInputRange instead if we need a shared base
• add features like orientation (?)
• write docs

[jdelight]

This is a great help @tlouisse thank you! Looking at the example above it all seems very easy to follow which is great. Just a thought - are there any concerns that we use a very different approach for the multi-thumb slider vs the single thumb? are there any ways to extend or amend the LionInputRange to allow it to be used in both cases?

Anyway we'll take a closer look - I'm not working on this daily so apologies if the progress is intermittent but it's great to have this level of support from yourself and others.

[tlouisse]

Yeah, I agree we need to strive for a similar approach in both ranges. So feel free to use native inputs inside the _inputNode instead in your final component.
Or... we could go for the "aria approach" in LionInputRange as well. If that works well in all screen readers, it would personally have my preference, as it doesn't need styling in light dom....
Any thoughts @daKmoR @jorenbroekema @gerjanvangeest ?

[tlouisse]

@jdelight I think we should go for the solution where you add two native (input[type=range])sliders, to make things easier for now and conform with our current solution. Also, as an added benefit, we will get a proper drag/swipe interface on mobile for free then, plus it aligns best with your current POC :)

As wrt extending: we should aim for LionInputRangeMulti extends LionInputRange here indeed (instead of extending LionField, which is a superclass of LionInputRange, so conceptually very close).

Be careful to make sure the parser is defined on the prototype of LionInputRange first:
https://github.com/ing-bank/lion/blob/master/packages/input-range/src/LionInputRange.js#L73

So that should become (instead of the line in the constructor):

parser(value) {
  return parseFloat(value);
}

Now the parser defined in our poc will win from its parent

[jorenbroekema]

Agreed with trying to extend LionInputRange, amending it where it makes sense. If we can prevent needing to style in lightDOM like we currently do (because ::slotted doesn't work for non-tree abiding pseudo elements), that would be nicer indeed, but I haven't looked into it thoroughly to judge how feasible it is