I was looking at the documentation of the Slider plugin to see how you specify a scale that is not just linear between a minimum and a maximum, for example a set of contiguous intervals with different scales, or an interval with "gaps" (i.e. subitervals that cannot be selected), and to my astonishment I find out there isn't any support for such a thing whatsoever.

The ONLY kind of slider you can build is one with a linear scale, uniform between the minimum and the maximum. That's pathetic.

You should provide a way to specify a set of non-overlapping intervals (not necessarily contiguous), each with the initial and final value, each with the initial and final position of the handle in % of the total size of the slider, and optionally each with a different value of "step".

So one could build a slider that looks, for example, like this:

0--1--2--10--20--30--100--150--200

I'm really astonished that such a basic feature isn't already there. It's the bare minimum one would expect from a bloated plugin such as ui.slider.

Also it would be nice to have a built-in option for a logaritmic slider so one wouldn't have to build that from scratch.

Hello,

Currently we using the following jQuery UI libraries on our websites:

• jQuery UI - v1.11.1
• jQuery UI - v1.11.4

The Google Chrome browser Audits tool detects them as vulnerable. Please find these links for more details:

• ​https://snyk.io/vuln/npm:jquery-ui?lh@1.11.1
• ​https://snyk.io/vuln/npm:jquery-ui?lh@1.11.4

Can you please confirm if this is a legit issue? If so, then would you please advise hot to fix it?

Thank you, Rustam.

currently (JUI-1.12), "instance invocation" still does not have same luxury on return types compared with "plugin invocation" (​http://learn.jquery.com/jquery-ui/widget-factory/widget-method-invocation/#return-types).

"Most methods invoked through the widget's plugin will return a jQuery object so the method call can be chained with additional jQuery methods. This is even true of methods that return undefined when invoked on the instance."

Instance invocation produce verbose statement. The more additional statements added, the more ugly they look. For me, this is the main barrier why i decided not to use instance invocation. Beside this weakness, i recognize the potential advantage on using instance invocation: a better IDE recognition and error inspection.

This inconsistency (instance and plugin return type) is caused by how we declare return statement inside the method. If we declare it as jQuery object, we get same condition as before: we still can't do method chaining with "instance invocation". If we declare it as instance object, we can do method chaining on "instance invocation" but it breaks method chaining on "plugin invocation".

Another determining factor is if ( methodValue !== instance && methodValue !== undefined ) statement inside $.widget.bridge body. It is the source of magical chaining on "plugin invocation". We expect the same magic for "instance invocation".

What we expect is if the method returns instance object (return statement declaration), the bridge automatically converts it as jQuery object so the chaining can be applied on both kind.

The implication of this are:

1. We can't obtain instance object anymore using "plugin invocation" other than "instance" keyword.

$.widget("ns.mywidget", {
    myMethod: function(){
        return this;
    },
    otherMethod: function(){
        // nothing to return
    }
});

// now, these statement is magically returning jQuery:
$elm.mywidget("myMethod");
$elm.mywidget("otherMethod"); // nothing new on this one

// this method is still returning instance:
$elm.mywidget("instance");

2. The consummer of "plugin invocation" must explicitly call "instance" method if it really want to obtain instance object.

// before
$elm.mywidget("method1") // method1 returns jQuery
    .mywidget("method2") // method2 returns instance
    .method3()           // see the style switching

// after
$elm.mywidget("method1")
    .mywidget("method2")  // now, method2 returns jQuery
    .mywidget("instance") // explicitly
    .method3()

3. The only problem (if any) is on the custom user widget, whether it is modified/derived version of standard JUI or brand new. If user declare the public method returns instance than this will breaks the widget.

As far as i know, most of (if not all) public instance methods on the standard JUI widget are not returns instance. This mean the consumer of that widget is always get anything other than instance object. I thing this is save to add the missing return statement (which is returning instance).