This kind of slider should ALWAYS have the middle part movable; IE grabbing it would move both handles at the same time.<p>For reference this is how Unity does it:
<a href="https://docs.unity3d.com/StaticFiles/ScriptRefImages/EditorGUILayoutMinMaxSlider.png" rel="nofollow">https://docs.unity3d.com/StaticFiles/ScriptRefImages/EditorG...</a>
Hey, author here, glad to see it popping up on HN.<p>I see people started opening issues and leaving bug reports here. I’ll try to go through them tomorrow (it is getting late here).<p>I created it because I needed it for my generative drawings. I prefer dragging a slider and seeing how the image changes, more than typing in a number.<p>I really tried to keep it minimal.
Playing around with this and immediately hit a bug. If I drag the sliders to 100 - 100 and then try to do 99 - 99, I can't. I can't get there from 99 - 100, and I can't get there from 98 - 99. The only way to get to 99 - 99 is to drag the lower bound somewhere lower than 98. If I'm at 98 - 99 and I drag it down to 97 - 99, then I can get to 99 - 99.<p>This bug can occur anywhere, it was just easiest to hit at 99 - 99 because that's right next to one of the ends of the slider. More generally, if I get to any X - X, then I drag one end of the slider by 1 step, I can't drag the other end of the slider into that gap. The only way to close that gap is to drag the other end further away first.
This is cool! I have always thought that the HTML <input type=range> input needed a dual-value implementation because that makes a lot of sense. Consider the use case "I want to filter products with at least X widgets but no more than Y".<p>However, I found a bug in Firefox I want to highlight:<p>Any time I click on a min or max handle they change change the value one step up or down.<p>If I make an effort to click in the dead center of the handle it does not change. If I click slightly to the left the selected value will decrease one step. If I click slightly on the right side of the handle it will increase.<p>I would expect the value to _only_ change when I make an actual action to change it by moving my mouse pointer with the button held down.
The fact that this works with keyboard is wonderful. It correctly works, too, meaning I can hold shift-tab to move backwards. Wonderfully done. That's such a small thing, and I just wanted to express my gratitude for getting that interaction correct.
For my company design system, an intern came up with a side by side POC like that but there was always pixels from one input jumping a bit and we couldn't make it work, so a second intern came up with a solution with 2 overlapping input range.
Very cool, I always used the jQuery UI slider when I needed a range input, which forced me to add jQuery and jQuery UI to my page, just for a single slider. This is very nice!<p>Edit: is there a chance to get a premade plain JS file to use, instead of an ESM module?
Is this the right place to report bugs? The handles in the first two examples trap touch interaction blocking scroll. The latter three examples don't. This has a side effect of not being able to 'drag up to reveal the labels underneath ones fingers since it just scrolls the page, keeping the labels underway the finger.
> The "native" part is somewhat open for discussion. I call it native because the library uses two native HTML range inputs. This means that all of the native interactions and accessibility features are preserved.<p>My dividing line is: if it needs Javascript to work as intended, it's not native anymore.
Thankyou! I was looking for this when I created <a href="https://spodj.intermer.net/" rel="nofollow">https://spodj.intermer.net/</a><p>I ended up having to use react badly to get the functionality I required as I'm a terrible front end developer.
for my local install of codemirror I styled a (single) range control as the drag-to-resize border between my editor iframe (on the left) and my preview iframe (on the right) and was about to get into doing the same for the individual html, css and javascript editor iframes within the editor iframe. so I'm looking forward to seeing whether this component will be a one stop shop for that solution. thanks for this, OP
Very clever!<p>Totally unrelated to this project, just a general UI question: does anyone like these inputs? Every time there is a number input next to one, I use that instead. Seems the upper limit of “ticks” you can have on one before it becomes unusable is like… 10?<p>Proper number inputs support all the same features (min, max, arrow keys to increment/decrement), but you can also just input an exact number. The range does visualize min, max, and current value relative to those nicely, but it’s annoying to actually use as an input more often than not.<p>The only real exception is for ranges of 0-100 type things, where the exact value doesn’t need to be precise, just roughly somewhere on that 1-100 scale. Eyeballing it is enough here, you don’t feel frustrated that you can’t use your thumb to get exactly 71. Volume slider, etc.
The native slider is hideous as f and further offends me by being called a range. Why are stupid simple things missing like display the value? We could even have a same name number input that displays the set value or an <input for=""<p>html forms in general got very little love. They should be taken to the drawing board along with sql and get some relation therapist to blame the earlier for the endless fighting. over the years of growing up together json made an effort to make the marriage work but html forms are very stubborn and unreasonable.<p>Things actually got worse when pressing the back button erased the fields. What we wanted was a way to put the same form with the same values back on the page after failed validation. I have backends where that stuff takes up 60% of the code. imagine <form src="foobar.json"/> with a nice widget displaying the key value pairs, with outlines for nested fieldsets?<p>anyway, thanks for the nice dual slider. my own experiments didn't result in something nice enough that i would dare use.<p>I would like to see a contest with cash prizes for designing better html forms with backwards compatibility. Winning entries should be put in the spec. Im sure we would pay plenty if it would ease the suffering. :)