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.
Native dual-range input
11–20 of 51 posts
Re: Native dual-range input
#12Very 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! Edit: is there a chance to get a premade plain JS file to use, instead of an ESM module?
You can grab this and then remove the "export default" line at the end.
https://cdn.jsdelivr.net/npm/@stanko/dual-range-input@0.9.8/...
Don't forget the CSS
https://cdn.jsdelivr.net/npm/@stanko/dual-range-input@0.9.8/...
Re: Native dual-range input
#13Very clever! 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? 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 anyone like these inputs?
We've A/B tested a slider against a textbox with plus and minus buttons (banking, on mobile) and the latter seemed to work better (as in fewer users cancelled the flow).
I'm not pretending this finding can be generalised, though.
Re: Native dual-range input
#14Hey, author here, glad to see it popping up on HN.
I see people started opening issues and leaving bug reports here. I’ll try to go through them tomorrow (it is getting late here).
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.
I really tried to keep it minimal.
Re: Native dual-range input
#15Very clever! 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? 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 anyone like these inputs? We've A/B tested a slider against a textbox with plus and minus buttons (banking, on mobile) and the latter seemed to work better (as in fewer users cancelled the flow). I'm not pretending this finding can be generalised, though.
I can't imagine a banking interaction where the amount of money is not a precise value.
What use cases motivated the testing of a slider?
Re: Native dual-range input
#16The 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 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.
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 with a nice widget displaying the key value pairs, with outlines for nested fieldsets?
anyway, thanks for the nice dual slider. my own experiments didn't result in something nice enough that i would dare use.
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. :)
Re: Native dual-range input
#17Earlier quoted context omitted.
> does anyone like these inputs? We've A/B tested a slider against a textbox with plus and minus buttons (banking, on mobile) and the latter seemed to work better (as in fewer users cancelled the flow). I'm not pretending this finding can be generalised, though.
I can't imagine a banking interaction where the amount of money is not a precise value. What use cases motivated the testing of a slider?
I believe it was some mortgage calculator and it jumped by 10k steps.
Re: Native dual-range input
#18Playing 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. This bug can occur anywhere, it was just easiest to hit at 99 - 99 b…
100-100 -> 99-100 -> 99-99 works for me in Chromium on desktop Linux. I do have a different visual bug. If I start at 23-25 and then drag to 24-25, the right knob at 25 shifts by a few pixels. Drag the left knob back to 23 and the right knob also shifts back.
Ah yes I should have specified browser engine. My bug was in Safari on macOS.
Re: Native dual-range input
#19This kind of slider should ALWAYS have the middle part movable; IE grabbing it would move both handles at the same time.
For reference this is how Unity does it: https://docs.unity3d.com/StaticFiles/ScriptRefImages/EditorG...
Re: Native dual-range input
#20Playing 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. This bug can occur anywhere, it was just easiest to hit at 99 - 99 b…
[deleted]