Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native dual-range input

muffinman.io

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Native dual-range input

#41

Post by stankot »

Y-bar wrote: post #37
rpastuszak wrote: post #34

Earlier quoted context omitted.

> 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). Intere…

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.

Re: Native dual-range input

#42

Post by jasonlotito »

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.

Re: Native dual-range input

#43

Post by hokkos »

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.

Re: Native dual-range input

#44

Post by stankot »

cosmotic wrote: post #11

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.

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

Re: Native dual-range input

#45

Post by KTibow »

stankot wrote: post #41
Y-bar wrote: post #37

Earlier quoted context omitted.

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). Intere…

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.

Plus it needs JS to work (the DOM's value has to be synced with the attribute value for this selector to work)

Re: Native dual-range input

#46

Post by extra88 »

Rygian wrote: post #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.

Usually but it's not entirely clear cut. The 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.

Re: Native dual-range input

#47

Post by jcelerier »

corytheboyd wrote: post #4

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 anyone like these inputs?

I implemented one in https://ossia.io but in practice a draggable spinbox is much more useable

Re: Native dual-range input

#48

Post by rpastuszak »

stankot wrote: post #41
Y-bar wrote: post #37

Earlier quoted context omitted.

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). Intere…

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.

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.

Re: Native dual-range input

#49

Post by stankot »

Y-bar wrote: post #29

This is cool! I have always thought that the HTML 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…

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.

Re: Native dual-range input

#50

Post by stankot »

stankot wrote: post #39
lilyball wrote: post #5

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 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.

I just released a fix for it and updated the blog post.
Post reply on HN