Neat! I love this
Native dual-range input
31–40 of 51 posts
Re: Native dual-range input
#32Clever!
It probably can be made to work javascript-less, just make the CSS width-calculation more sophisticated, and dependent on the slider values.
Re: Native dual-range input
#33> 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.
My dividing line is: if it needs Javascript to work as intended, it's not native anymore.
Re: Native dual-range input
#34Clever! It probably can be made to work javascript-less, just make the CSS width-calculation more sophisticated, and dependent on the slider values.
> dependent on the slider values
That’s the tricky part for a JS free implementation, right? Or am I missing something?
Re: Native dual-range input
#35The 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 g…
And then some wonder why people resort to js-controlled spas and tend to forget how they cursed after their “simple html form” deleted input due to navigation or accidental refresh. Input is the most valuable data in a program because it cannot he recalculated and usually reqiures work to produce. Anything that doesn’t get this principle sucks. That said, I don’t think src=form.json would help. Some type of a local p…
Most egregious thing is many times when people roll their own forms they end up actually removing things. The amount of forms I encounter where autofill and spellcheck are broken is crazy.
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.
Re: Native dual-range input
#36> 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. My dividing line is: if it needs Javascript to work as intended, it's not native anymore.
I agree. And I think that's the common usage?
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.
Re: Native dual-range input
#37Clever! It probably can be made to work javascript-less, just make the CSS width-calculation more sophisticated, and dependent on the slider values.
> dependent on the slider values That’s the tricky part for a JS free implementation, right? Or am I missing something?
I think they are suggesting using something like this, which does work to target certain attributes:
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.
Re: Native dual-range input
#38Hey, 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.
Goshdarn I love this post. I enjoyed my morning coffee while looking at the calculations, and the description of the debugging mode. It's a clever usage of native components. Currently my experience is with SwiftUI and it's almost too easy to make your own components. However that doesn't make it the best option as you described, native components are often very full-featured. I checked your post on Firefox on iOS, w…
Thank you, comments like yours really make my day!
Re: Native dual-range input
#39Playing 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…
Nice catch! Actually I thought of this and it works in Chrome and Firefox, but it seems that Safari is not triggering the focus event on mouse down, but only when you start moving the slider. Thank you for the report, I'll make sure to fix it.
Re: Native dual-range input
#40Very 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…
Anytime you don't care about exact values and want a quick way to nudge the value in a live visual environment they are great.
For example in an editor for procedurally generated stuff like random maps, texture, sounds, etc.