[HN Gopher] Native dual-range input
___________________________________________________________________
Native dual-range input
Author : Wolfr_
Score : 248 points
Date : 2024-12-04 18:39 UTC (1 days ago)
(HTM) web link (muffinman.io)
(TXT) w3m dump (muffinman.io)
| rafram wrote:
| This is very neat! Nice work.
| echoangle wrote:
| 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!
|
| Edit: is there a chance to get a premade plain JS file to use,
| instead of an ESM module?
| tln wrote:
| 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/...
| corytheboyd wrote:
| Very 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 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.
| encoderer wrote:
| I could make the argument that a number input plus a labeled
| slider is superior to number input plus a text label of min/max
| corytheboyd wrote:
| Makes sense to me, the range input is effectively acting as
| the label here, it just happens to be an input as well. Best
| (better?) of both worlds.
| yreg wrote:
| > 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.
| Rygian wrote:
| 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?
| yreg wrote:
| I believe it was some mortgage calculator and it jumped by
| 10k steps.
| lmm wrote:
| Wonga.com was (briefly) a huge success story with their
| "two slider" interface. Perhaps because it made it easy to
| see how the output changed with the input.
| wruza wrote:
| I almost never use them. In sd webui I change resolution often,
| so I patched some divs to contain [512, 640, 768, ...] and
| click these instead. Not sure if this slider control should
| even exist in a flow context, because it cannot be made
| scrollable like a volume range.
|
| 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?
| zapparoni wrote:
| 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.
| jcelerier wrote:
| > does anyone like these inputs?
|
| I implemented one in https://ossia.io but in practice a
| draggable spinbox is much more useable
| lilyball wrote:
| 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.
|
| 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.
| encoderer wrote:
| ^ and this is why I love making developer tools.
| Arnavion wrote:
| 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.
| lilyball wrote:
| Ah yes I should have specified browser engine. My bug was in
| Safari on macOS.
| stankot wrote:
| 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.
| stankot wrote:
| I just released a fix for it and updated the blog post.
| cosmotic wrote:
| 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.
| stankot wrote:
| If you can replicate this, please open a github issue [1].
|
| 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.
|
| [1] https://github.com/Stanko/dual-range-input/issues
| stankot wrote:
| Hey, 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.
| bartvk wrote:
| 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,
| which is arguably an obscure browser, and it worked fine.
|
| Very well done.
| stankot wrote:
| Thank you, comments like yours really make my day!
| throwaway14356 wrote:
| 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=""
|
| 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. :)
| wruza wrote:
| 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 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.
| whywhywhywhy wrote:
| 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.
| maxlin wrote:
| This 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...
| worthless-trash wrote:
| As a counterpoint, i would never have clicked the middle part,
| the current view in my mind was that this was a modified
| slider, not another new widget entirely.
|
| "ALWAYS" might be a bit of an overstatement.
| fitsumbelay wrote:
| 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
| kn100 wrote:
| totally pointless to implement this honestly but I was
| disappointed it didn't support multi touch :p
| Y-bar wrote:
| 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".
|
| 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.
| stankot wrote:
| Honestly, I don't think that is a bug. All examples are quite
| dense and the thumb covers multiple steps on the track. Firefox
| then translates every click like you clicked directly on the
| track. The library doesn't interfere with it in any way, it is
| how Firefox works.
| Intermernet wrote:
| Thankyou! I was looking for this when I created
| https://spodj.intermer.net/
|
| I ended up having to use react badly to get the functionality I
| required as I'm a terrible front end developer.
| tobyhinloopen wrote:
| Neat! I love this
| bmacho wrote:
| Clever!
|
| It probably can be made to work javascript-less, just make the
| CSS width-calculation more sophisticated, and dependent on the
| slider values.
| rpastuszak wrote:
| > dependent on the slider values
|
| That's the tricky part for a JS free implementation, right? Or
| am I missing something?
| Y-bar wrote:
| 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.
| stankot wrote:
| I think it can be theoretically done, like it is mentioned
| in the comment above, but you would need a new block of CSS
| for every slider min/max/step combination. It feels it
| would be harder to maintain than the javascript version.
| KTibow wrote:
| Plus it needs JS to work (the DOM's value has to be
| synced with the attribute value for this selector to
| work)
| rpastuszak wrote:
| Yeah I was thinking about something similar, e.g. using
| attr()* and a pseudoelement to pass the value from DOM to
| CSS of a ::before/::after pseudo-element.
|
| 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.
| Rygian wrote:
| > 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.
| onli wrote:
| 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.
| extra88 wrote:
| Usually but it's not entirely clear cut. The <dialog> element
| is native but you have to use JavaScript to open it in the
| modal state. Before the popover attribute, you couldn't open it
| at all without JavaScript.
|
| 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.
| jasonlotito wrote:
| 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.
| hokkos wrote:
| 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.
___________________________________________________________________
(page generated 2024-12-05 23:01 UTC)