Non-jquery slider

[jasongrout]

Looking at slider options, here is a simple slider that appears to satisfy our needs: http://refreshless.com/nouislider/ (basic typescript definitions here: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/nouislider/nouislider.d.ts)

@SylvainCorlay, @jdfreder, @afshin - what do you guys think of moving to use nouislider?

Another possibility is to use the browser sliders (they are pretty much standardized now, though the UI customizations vary greatly: https://css-tricks.com/styling-cross-browser-compatible-range-inputs-css/. The problem there is that we wouldn't have range sliders, which would be a regression.

[SylvainCorlay]

👎 on native browser sliders because of absence of range sliders that are used a lot.

[SylvainCorlay]

nouislider seems to only be about range sliders.

[SylvainCorlay]

Re: the current jquery ui slider, I just wanted to communicate that there is no problem with having jquery-based widgets.
It just happens that the slider is the only core widget to make use of jquery and it is the only reason why jupyter-js-widgets depends on jquery.

[jasongrout]

and jquery-ui...

[jasongrout]

nouislider has range sliders, but it's not only about range sliders...

[afshin]

noUiSlider seems reasonable enough to me. I don't have any experience with it, but it doesn't seem bloated to me, which is my main concern about external libs.

It might seem silly to ask, but are we cool with WTFPL?

[jasongrout]

I looked into the license a bit. Wikipedia has a bunch of links where the FSF acknowledges it, it seems that various people (whatever that's worth) say it is basically a public domain dedication. The license author even says you can relicense work ("The WTFPL lets you relicense the work under any other license." on http://www.wtfpl.net/faq/), so even if we're not happy with it, it seems we can change the license and maintain a fork.

[jasongrout]

This would also probably fix #655.

[dakoop]

Apparently, new HTML specs have a "multiple" attribute for range sliders, and there is a polyfill: http://leaverou.github.io/multirange/

[SylvainCorlay]

@jasongrout the one-value HTML5 sliders works well and seems to be pretty well supported across the board. I started working on this in the plane for Austin.

However this will probably require us to have a well-separated view for the range...

[gnestor]

@SylvainCorlay Do you think it makes sense for me to try out this multirange polyfill for the native HTML slider? Another thing to consider: If we are going to replace the jQuery slider with a native one, should we not do the same for Dropdowns and Progress widgets? If so, then I think it would make sense to address the

Give the widgets a facelift. Maybe material-ui? Home spun design?

roadmap item at the same time and implement a consistent style across both native and non-native elements.

[maxnoy]

Additional option -- ion.rangeSlider. Supports both single and range slider modes. More demos from shiny.

[jasongrout]

Just saw this announcement about changes in the jquery-ui infrastructure going forward: http://blog.jqueryui.com/2017/12/the-future-of-jquery-ui-and-jquery-mobile/

I think that's another thing in favor of finding an alternative.

[den-run-ai]

I found few range sliders with more useful features, thanks to @vidartf for pointing to this issue:

#2249

[jasongrout]

It might seem silly to ask, but are we cool with WTFPL?

It looks like nouislider is now licensed MIT, as of about a month ago.

[jasongrout]

A brief search still turned up these viable alternatives:

1. https://github.com/leongersen/noUiSlider
2. https://github.com/IonDen/ion.rangeSlider
3. https://github.com/sghall/react-compound-slider
4. https://github.com/react-component/slider

plus there are libraries like blueprintjs, etc.

[ibdafna]

As a part of the January 2020 meeting (#2641), we discussed the alternatives listed above, in addition to building our own implementation. The main considerations were keeping the slider as simple as possible - with range slider support, and reducing dependencies such as JQuery and JQuery-UI.

Below is a brief summary of all alternatives considered, including pros and cons:

1. Multirange slider. This is a very lightweight library which polyfills native HTML5 sliders to allow for multi-handle sliders. It was built in anticipation of the official HTML spec adding support for such multi-handle sliders, however that suggeted addition to the spec has been dropped, and as a result the Multirange library is no longer actively developed. When testing, we found some rendering artefacts on browsers like Safari.

2. noUiSlider. A relatively lightweight, but feature-packed slider package with no dependencies. Supports everything the JQuery-UI's slider implementation has. Still actively developed and growing in populatiry. Minimalist styling also makes it appealing to us as it is relatively close to the current slider styling.

3. ion.rangeSlider. This is probably the Ferrari of sliders - highly polished with slick graphics and full feature set which exceeds the current slider functionality. However, it is quite heavy and depends on JQuery, which we are looking to move away from in the future. Although visually appealing, we found the styling quite far from the minimalist visuals we are looking for.

4. rangeslider.js. Another HTML5 polyfill which depends on JQuery. It is also lacks multi-handle functionality which makes it an unsuitable candidate to replace our current implementation.

We voted in favour of noUiSlider as it has no dependencies, and although it is quite feature-packed, we can expose only a part of the API which will keep functionality in line with what is currently available.

We also agreed that, if needed, migration from noUiSlider to any custom implementation should be relatively simple in the future and won't require a major release.

[ibdafna]

@jasongrout @SylvainCorlay @jtpio @mbektasbbg @vidartf @pbugnion @martinRenou

[jasongrout]

@ibdafna - can you list the other alternatives we considered, perhaps with a brief summary of the discussion about each?

[ibdafna]

Thanks, @jasongrout - I have added this to my comment above!

[afshin]

Does anybody have an opinion re: interact.js? It seems attractive: it supports touch events and it works on DOM nodes so it can be used within a Widget lifecycle.
https://interactjs.io/
https://www.npmjs.com/package/interactjs/v/1.8.2

[jasongrout]

As far as I can tell, interact.js is not a slider per se, but a library unifying touch and mouse events on top of which a slider could be built. Are you asking if we've thought about building our own slider on top of something like interact.js?

[afshin]

Are you asking if we've thought about building our own slider on top of something like interact.js?

Yes. One of their examples is how you would implement a slider. It seems a bit higher level than Lumino drag drop support.

[jasongrout]

One of their examples is how you would implement a slider.

Can you point to that example? I can't find it.

[afshin]

It's the first example on their docs page: https://interactjs.io/docs/

The code is linked to on that page, so if you just want to see the example:
https://codepen.io/taye/pen/GgpxNq

[afshin]

[afshin]

Ah I didn't realize @ibdafna was so far along in his slider PR.

[jasongrout]

Interesting. That demo has a max slider value of 0.87 for me (Firefox, macOS), which seems odd.

Yes, we're working on getting @ibdafna's nouislider implementation in, which is what we decided on at the widgets sprint. Thanks for pointing out an alternative, though!

[afshin]

Oh interesting, it must be a bug. It has that same behavior for me in both Firefox and Chrome.