Native dual-range input
muffinman.io
muffinman.io
For reference this is how Unity does it: https://docs.unity3d.com/StaticFiles/ScriptRefImages/EditorG...
"ALWAYS" might be a bit of an overstatement.
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.
Very well done.
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.
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.
However, I found a bug in Firefox I want to highlight:
Any time I click on a min or max handle they change change the value one step up or down.
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.
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.
Edit: is there a chance to get a premade plain JS file to use, instead of an ESM module?
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/...
Which browser and OS are you using? Because this library doesn't do anything regarding the scroll blocking (because it is using native inputs). On my phone (iOS) scroll is blocked on all input[type=range] elements, styled or not.
My dividing line is: if it needs Javascript to work as intended, it's not native anymore.
I still get what the author is aiming at though, using combined regular sliders instead of implementing a div soup animated by js moved this a lot closer to a native solution. Probably closest it can be, if the javascript can't be replaced by clever css.
It's still a very useful widget to have available, and that space was missing implementations. Native or not.
There are also native, vanilla JavaScript methods for things like form validation that I would consider distinct from a library that doesn't use the browser's internal validation tooling at all.
I ended up having to use react badly to get the functionality I required as I'm a terrible front end developer.
It probably can be made to work javascript-less, just make the CSS width-calculation more sophisticated, and dependent on the slider values.
That’s the tricky part for a JS free implementation, right? Or am I missing something?
input[value="5"] { width: 20%; }
This could then be combined with the sibling selector to target the other one
input[value="5"] + input[value="11"] { width: 80%; }
Though I am unsure how to make it entirely workable (you probably need a simple event listener to set the DOM node value to the dynamic form value). Interesting exercise if nothing else, and I think it could be doable to reach a working solution.
But that still feels like asking for trouble:)
Luckily I need to leave the house now, I'm feeling CSS naughty.
* IIRC support for anything besides `content:` is still very unstable.
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 visualize min, max, and current value relative to those nicely, but it’s annoying to actually use as an input more often than not.
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.
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.
What use cases motivated the testing of a slider?
I also somewhat like unix style numeric inputs because you can grab a bar between the arrows and drag it to change the value. No long range required.
Ranges with sticky points are somewhat okay, e.g. Virtualbox settings stick to 2^n values for RAM and some integer disk GBs. But these intermediate values are just nonsense and nobody ever selected 7527MB of RAM by non-mistake.
Bonus points for Ubuntu keyboard repeat/delay settings which don’t show the numeric values at all. You set delay to 178 or maybe 223 or maybe 202. Who cares about muscle memory, right?
For example in an editor for procedurally generated stuff like random maps, texture, sounds, etc.
I implemented one in https://ossia.io but in practice a draggable spinbox is much more useable
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 <form src="foobar.json"/> 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. :)
That said, I don’t think src=form.json would help. Some type of a local permanent storage is basically required for app-level interaction, because the page state is so transient and fragile. I’d say it should be <form storage="foo."> and all controls would be saved as foo.<name> into localStorage. With <form storage="foo." reset> received from backend to reset it explicitly if needed.
Maybe it’s some “best practice” library popular in the react ecosystem, I see it often enough to suspect that but autofill and spellcheck are my input and my business and a form shouldn’t decide if they’re enabled.