selectable("destroy") could remove "ui-selected" class

[hubquery]

When calling selectable("destroy"), should removeClass("ui-selected") be called as well as the current removeClass("ui-selectee")?

Some people might want to preserve the ui-selected items when the selectable is destroyed, though, in which case maybe just the documentation should be adjusted to say "This will return the element back to its pre-init state, leaving selected items with the ui-selected class".

[rdworth]

The current behavior is correct. I could see us updating the docs, but basically when we say "return the element back to its pre-init state" we mean that destroy corresponds to init, so what is done in init is un-done by destroy. As init doesn't add the ui-selected class, then destroy shouldn't remove it.

[rdworth]

An example for comparison, I don't think anyone would expect .draggable('destroy') to return the draggable element to where it was before init, even if that's technically part of its pre-init state.

[Scott González]

Milestone TBD deleted

[Lary666]

To be honest, it isn't obvious that the ui-selected class will remain. This is a class used by the plugin and most of the time, when you will call Destroy, you will want to clear the selection and put an end the selection process. The draggable comparison is not valid because it does not add a ui-draggable-dragged class.

[tj.vantoll]

Just as an fyi if you really need this behavior you can write an extension that does this really easily:

$.widget( "ui.selectable", $.ui.selectable, {
    _destroy: function() {
        this.selectees.removeClass( "ui-selected" );
        this._super();
    }
});

Example: ​http://jsfiddle.net/tj_vantoll/bejfhsfm/