wc-slider (An alternative to the range input)

By Maksim Chernyshev

HTML is brilliant; it's an ever-growing standard; CSS is also pretty amazing! I say this because I was bored over the evenings this week and brushed off an old thing I started years ago to help me with the inability to style range inputs. You can do some cool styling on range inputs now, but when I created my initial component, it wasn't easy and involved many vendor prefixes, with some target browsers unable to handle even those. So I decided to write a component to get our designer's desired effect.

But I was bored this week, so I decided to revisit it; you can see the result on JSFiddle.

It was a lot of fun doing this, I'm not sure if I'll ever need it again, but it was a valuable learning experience. Asking for help from a mate meant that she could echo back something I've said to her many times before: "Have you tried flex?", so embarrassing, but it just goes to show! One issue was that I was sticking to the original CSS too much and didn't have to cope with variable-sized wc-sliders. You see, the little arrows behind the slider element moved depending on the number of elements in the slider.

The Drag-and-Drop mechanism took the most time and - as a result of checking my workings - I clocked I was using the getters for range, colourRange and deselectedRange far too much. I moved these to Private class features and only calculate them on render(). Thanks to the dictates of working with a designer, I also spent a fair bit of effort working with colours and gradients - a bit of a ballache, TBH, but I've got the functions now so that I can use them again in the future!

I do like the invertColor(hex, bw) though. That's tremendous fun and might be useful should you check what colour you need to set text atop different coloured backgrounds. Looking at it again now, though, I think the none bw might be a little borked; I'll fix it as and when I've time.

It's a bit CSS-heavy, but no worse for that, TBH; if you can do something with CSS, then it's better than firing up JS - let the browser do the work!

From the README:

• Dragging the slider element will alter the value surfaced by the component from its value attribute (should the number in which the drop ends be greater than or equal to the constrain-min or less than or equal to the constrain-max)
• Clicking on the numbers shown at the top of each step will alter the value surfaced by the component from its value attribute (should the number be greater than or equal to the constrain-min or less than or equal to the constrain-max).
• Clicking on the triangles on either side of the slider will alter the value surfaced by the component from its value attribute by +/- 1 (should the number resulting from the click be greater than or equal to the constrain-min or less than or equal to the constrain-max).

As you can doubtless see, there are three ways of changing the value and - given the work I put into checking the bugger, no way for an invalid value to be produced - though you might not like the value. Having said that, if you manage to break it, please let me know, so I can fix it!

It has some default attributes so that you can test it for your use case.

Again, from the README:

• The range of numbers, inclusive of min and max, should not be too large - tests have found that the ranges should not have more than 15 numbers, but YMMV.

One thing to consider in the future is whether or not to allow for a comma-separated list of hex values so that designers can adequately define what colours should appear on the wc-slider.