• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Selectable

Page history last edited by Paul Bakaus 14 years ago

 

type: interaction

release: 1.5

status: refactor in planning/development

documentation: http://docs.jquery.com/UI/Selectable

demo: http://jqueryui.com/demos/selectable

in-progress refactor demo: http://jquery-ui.googlecode.com/svn/branches/labs/selectable/demos/selectable/default.html

 

 


 

1 - Description:

 

This interaction makes a set of items (descendants of a common container) mouse and keyboard selectable. A first attempt that only features mouse selecting (with some keyboard interaction) is already part of the current releases, documentation can be found here: http://docs.jquery.com/UI/Selectable

 

 


 

2 - Visual Design:

 

N/A

 


 

 

3 - Functional Specifications/Requirements:

 

Selecting items basically can be done using the mouse only, keyboard only, or a combination of both. Since all OS file managers have differences in implementation, it's important to know about these differences and be able to judge them. For instance, some behavioral differences between Explorer(win)/Finder(mac) are simply bugs, and should be fixed by our implementation, while others need to be handled individually for different operating systems (i.e. using the apple/cmd key instead ctrl on mac).

 

Functional requirements / Specifications

 

To better understand how a selection works, you have to know that there are often multiple states an item can have. In our environment, only two states are really relevant (there's a third under the hood called latestWithoutModifier, but it's not really related to the actual experience):

 

  1. selected
  2. focused

 

The 'focus' works very similar to the focus web developers know. Only one item can be focused at the time, and it is always the current context item. For instance, if you click on a selectable item, it's not only selected but also focused. There are situations though when the focus is not connected to a selection: Try opening Windows Explorer, and then hold down the Control key + up/down to move the dotted outline around the items, then try a shift selection. You'll see that the focused item is the anchor for the new shift selection. Important to note is that OS X does not have the focus state (at least not exposed in any way).

 

Below are the different ways to select or unselect items in a selectable:

 

  • Mouse selection (lasso)
    • Basic function is to start a mouse drag on the canvas (the outer element holding the items), which will create a lasso and 'capture' and 'decapture' elements by drawing the lasso around them.
    • Tolerance configuration ('touch', 'fit', 'intersect')
    • When starting the lasso, the current selection is cleared by default. The selection is not cleared if you hold down the (ctrl/cmd) key before initiating a lasso
    • Starting a lasso selection by starting to drag on a selectable item should be disabled by default. It makes implementing functionality on top extremely difficult (i.e. drag & drop) and is non standard behaviour in any operating system. It should be configurable though.
  • Mouse selection (click)
    • Click: Moves the focus to the clicked item. If clicked without a modifier, clears the current selection, and selects the newly focused item.
    • (Ctrl/cmd)+click: Toggles the selection of the clicked item. Does not affect the state of other selected items.
    • Shift+click: Selects all items between the first selected item and the clicked item. If you click a different item while holding shift (even if shift was released and pressed anew), the current selection is cleared, and a new selection is made, again between the first selected item and the clicked item.
  • Keyboard selection
    • Up/Down/Left/Right (arrows), Home/End: Moves the focus to the above, below, previous, next, first, last item in the selectable container. If pressed without a modifier, clears the current selection and selects the newly focused item.
    • (Ctrl/Cmd)+arrows/home/end: Moves the focus. Does not clear the current selection. Does not select the newly focused item. Allows for non-adjacent items to be selected using the keyboard.
    • Shift+arrows/home/end: Selects all items between the first selected element and the newly focused item.
    • (Ctrl/Cmd)+space: Toggles the selection of the focused item. Does not affect the state of other selected items. This makes it possible to select non-adjacent elements using only the keyboard, in combination with (ctrl/cmd)+arrows/home/end (non-destructive focus move).
    • Shift+space: Selects all items between the first selected element and the focused item. This is different than shift+arrows/home/end in that you would get to the focused item using (Ctrl/Cmd)+arrows/home/end wheres with shift+arrows/home/end the selection would follow the focus.
    • (Ctrl/Cmd)+A: Select All. Select all the items in the selectable container.

 

The drag problem

 

Every selectable implementation needs to be flexible enough to allow a selection to be dragged. However, a lot of detail in the implementation is actually required to make this possible - in fact it's so difficult that it seems that the OS X guys simply didn't manage to get it right. In OS X' Finder, you can of course drag items, but if you have multiple selected items, you cannot deselect them by clicking on one of those selected items (without holding modifiers). Let me explain to you why that is:

 

Both a selection and a drag are usually initiated on the 'mousedown' event. That means, as soon as you hold down your mouse button, the clicked item is selected. Since the order of events often can't be controlled, it means that without any special handling, the following would happen: With a selection of multiple items, you try to initiate a drag - the selectable though also listens for the mousedown, and handles it as click, therefore before the drag can happen, the other items around your selection are deselected. In order to prevent this, you must do the following: If you click on an item within a selection of multiple items, the selection action must occur on mouseup instead on mousedown. Linux/Windows get that right - OS X doesn't.

 

Functional changes of existing functionality in the refactor:

 

No significant features of the old selectable were removed during the refactor, meaning that everything can be achieved like before, but the style might be slightly different sometimes. See below the list of specific changes on existing functionality:

 

  • Events
    • 'selected' was renamed to 'select'
    • 'unselected' was renamed to 'deselect'
    • 'unselecting': removed, 'select' triggers instantly
    • 'selecting': removed, 'select' triggers instantly
    • ui hash changes:
      • ui.selected -> ui.added
      • ui.unselected -> ui.removed
  • Styling
    • Selectable container gets ui-selectable class and ui-widget class
    • All selectable items get the ui-selectable-item class
    • When an item is selected, it gets the ui-selected and ui-state-active classes
    • When an item gets the focus, it gets the ui-state-focus class. Only one item in a selectable container would have this class at a time.
    • .ui-selecting: removed
    • .ui-unselecting: removed
    • .ui-selectee -> .ui-selectable-item
    • .ui-selectable-helper -> .ui-selectable-lasso
    • lasso inline style of dotted border is removed. Now styled through .ui-selectable-lasso rule in ui.selectable.css
  • Options
    • autoRefresh: removed, call method selectable('refresh') instead
    • appendTo -> lasso.appendTo
    • distance -> lasso.distance
    • tolerance -> lasso.tolerance

 

Options/Methods/Events

  • options:
    • closest (Boolean | default: true)If set to true, the actual visually closest item gets selected when keyboard navigating, instead of the next in document order.
    • filter (Selector | default: '> *')

      Used to retrieve what the selectable items are in the root element.

    • keyboard (Boolean | default: true)

      Disables or enables keyboard selection (this does not affect mouse+key combinations).

    • lasso (Boolean/Hash | default: true)

      Disables or enables the lasso (can be optionally configured via hash).

      • distance (Integer | default: 1)

        Only related to lasso. Specifies the distance needed to drag before a drag is initiated

      • delay (Integer | default: 0)

        Only related to lasso. Specifies the delay in time needed before a drag is initiated.

      • cancel (Selector | default: ':input, option')

        Only related to lasso. Doesn't allow to initiate the lasso on specific element types

      • tolerance ('touch', 'fit', 'intersect' | default: 'touch')

        Only related to lasso. Specifies at what overlap the item is selected/deselected. 

      • appendTo (String, Selector | default: 'body')

        Only related to lasso. Determines to where the lasso is appended

         

  • methods:
    • selectable('select', item)

      Selects a specific item or multiple items. 'item' can be an index, a jQuery selector or DOM element.

    • selectable('deselect', [item])

      If no second argument is passed, all items are deselected. If a second argument is passed, only the passed elements are deselected. 'item' can be an index, a jQuery selector or DOM element.

    • selectable('refresh')

      Refreshes the list of items. Must be called when new items are added to the list, or items have been removed.

    • selectable('next', [event])

      Selects the next item.

    • selectable('previous', [event])

      Selects the previous item.

  • events:
    • start - fired when lasso is drawn
      • event: mousedown -> mousemove (dragstart)
      • ui hash: 'added'/'removed' is always empty
      • cancelable: no
    • beforeselect (is not triggered for programmatic selecting)
      • event: mousedown/mouseup/keydown/none
      • ui hash: includes previous information
      • cancelable: yes
    • select
      • event: mousedown/mouseup/keydown/none
      • ui hash: 'added' includes newly selected items, 'removed' is always empty
      • cancelable: no (see beforeselect)
    • deselect
      • event: mousedown/mouseup/keydown/none
      • ui hash: 'removed' includes deselected items, 'added' is always empty
      • cancelable: no
    • stop - fired when lasso selection is finished
      • event: mousemove -> mouseup (dragstop)
      • ui hash: 'added'/'removed' is filled
      • cancelable: no
    • change - happens whenever the selection has changed in any way
      • event: multiple
      • ui hash: includes the delta as 'added'/'filled'
      • cancelable: no
  • 'ui' object:
    • previousFocus (object[jQuery])
    • currentFocus (object[jQuery])
    • selection (object[jQuery])

      jQuery object that includes the current selected list of elements.

    • removed (object[jQuery], only for unselect event)

      If items are unselected, this is the list of unselected items.

    • added (object[jQuery], only for for select event)

      If items are being added to the selection, this is the list of added items.

    • lasso (Boolean, only for for mouse select events)

      If a lasso is used to select elements, the 'select' event includes this boolean.

       

 


 

4 - Markup & Style:

 

     4.1 Initial markup examples

 

     (Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )

 

     4.2 Recommended transformed HTML markup

 

     (The HTML markup structure and classes that will be used by the scripts in the enhanced version) 

 

     4.3 Accessibility recommendation

 

    (Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices) 

 

     4.4 CSS & Theme

 

    (Description of the CSS classes to be used for all states, how custom theming and Themeroller support will work.) 

 


 

5 - Latest version of plugin:

 

Default (featuring nested): 

http://jquery-ui.googlecode.com/svn/branches/labs/selectable/demos/selectable/default.html

 


 

6 - Open issues being discussed

 

(Use this area to place things that we're hashing out like featuresand options we're not sure we should include, questions about how this fits into UI and relates to other widgets and utilities, known problems, whether features should be broken across multiple releases, etc.)

 

Some tests scenarios that should be written up into unit tests:

On http://jquery-ui.googlecode.com/svn/branches/labs/selectable/demos/selectable/display-grid.html

1. Lasso from 1 to 2 (actual: selects 1 and 2)

2. Hold Ctrl

3. Ctrl+lasso from 4 to 5 (actual: focuses 4, selects 5. Expected: selects 4 and 5)

4. Ctrl+lasso from 7 to 8 (actual: focuses 7, selects 8. Expected: selects 7 and 8)

(Actual: 1, 2, 5, 8 selected. Expected: 1, 2, 4, 5, 7, 8 selected)

 

On http://jquery-ui.googlecode.com/svn/branches/labs/selectable/demos/selectable/display-grid.html

1. Click 2 (actual: selects 2)

2. Hold Shift

3. Shift+click 5 (actual: selects 2-5)

4. Shift+click 8 (actual: selects 2-8)

5. Release Shift (actual: 2-8 selected)

 

On http://jquery-ui.googlecode.com/svn/branches/labs/selectable/demos/selectable/display-grid.html

1. Click 2 (actual: selects 2)

2. Ctrl+down to 5 (actual: moves focus to 5 without selecting)

3. Ctrl+down to 8 (actual: moves focus to 8 without selecting)

4. Shift+space (actual: nothing happens. Expected: 2-8 selected)

This works with Ctrl+click on 2 followed by shift+click on 8. Same should work with keyboard only.

 

On http://jquery-ui.googlecode.com/svn/branches/labs/selectable/demos/selectable/display-grid.html sequence

1. Click 1 (actual: selects 1)

2. Hold Ctrl

3. Ctrl+click 5 (actual: adds 5 to selection)

4. Ctrl+click 9 (actual: adds 9 to selection)

5. Release Ctrl (actual: 1, 5, 9 selected)

 

Bug:

If you use ctrl+arrows to move the selector, you can use ctrl+spacebar to toggle the selection of an element, but once you do, it locks up. You can no longer toggle selection nor ctrl+arrow navigate the cursor. This bug is present on FF3.5/win but not IE6/win 

 

Bug:

Currently, clicking on a selectable element does not focus it.

 

A note from Maggie:

"For the selectable items, all state classes should be considered mutually exclusive - only one should be applied at a time.  This includes the state classes for -hover, -active, and -focus."

 


 

 

 

 

 

Comments (Show all 54)

Paul Bakaus said

at 9:19 am on Aug 27, 2009

I discussed this with Jörn previously, -1. Those are all options that are entirely irrelevant if you don't use a lasso and add up confusion while cluttering the option hash. In order to really highlight it, we would need to name them lassoDistance etc, which is much uglier.

Additionally, give me some time and I will come up with plenty of good usecases for disabling keyboard and/or lasso.

Richard D. Worth said

at 9:59 am on Aug 27, 2009

If they're irrelevant then they can and will be ignored. Not using a lasso should be up to the user. As I said, having them underneath the lasso option means you can't get and set them without getting and setting the entire lasso option. This is what happens right now with dialog buttons, and it's a pain.

Paul Bakaus said

at 11:08 am on Aug 28, 2009

Yep, but they don't make sense *without* the lasso option, so this doesn't seem to be an issue to me. Some of those options are pretty important in fact - tolerance is very important, as is distance/delay. I can give you thousands of usecases on those btw, I'm strong on drag & drop :)

Richard D. Worth said

at 11:41 am on Aug 28, 2009

Getting back to one of my central points, lasso shouldn't *be* an option. It's a feature that the user can use. Whether the lasso is visible or not can be determined by css. So having these options at the top level is not an issue. The issue with having them at a second level is that you have to be able to modify all options after init. So how would you modify just the appendTo option, or just the tolerance option, after init, without specifying the entire hash?

Paul Bakaus said

at 9:21 am on Aug 27, 2009

Extremely tricky. It's much easier for plugins like drag & drop, or even the slider, but in the case of selectables, the beforeselect event is actually extremely useful - it gives you the state *before* the selection has happened, and then lets you decide. Others thoughts?

Richard D. Worth said

at 9:46 am on Aug 27, 2009

That's what I'm suggesting be done for start, select, and deselect. Trigger them in time to give the before state, let the user cancel if they want. If they don't cancel, stop and change will trigger. change will communicate what happened where start, select, and deselect would communicate what tried to happen.

Paul Bakaus said

at 11:25 am on Aug 28, 2009

I don't think 'select' implies that you'll receive the state before the selection happened, so -1.

Richard D. Worth said

at 11:44 am on Aug 28, 2009

how does it not? All our plugins follow this same pattern.
draggable: start, drag, stop
sortable: start, sort, stop, change
slider: start, slide, stop, change
The event between start and stop is named by the name of the plugin. And the one I know for sure of that list that already follows the other half of this pattern is slider's slide. It's cancelable. There's no need for a beforeslide. slide let's you prevent a slide you don't consider valid. change notifies you of a slide that was successful.

Scott González said

at 1:21 pm on Aug 28, 2009

Isn't this how all native events work? You got a click event after the action occurs, but before the default reaction takes place.

Paul Bakaus said

at 9:28 am on Aug 27, 2009

The elements are in fact not selected before they're deselected - that's the first thing. You need to call the refresh method after adding those classes. Second, I can't replicate the issue - what browser/OS?

Richard D. Worth said

at 10:08 am on Aug 27, 2009

I was only selecting in that way before calling 'deselect' because calling 'select' was triggering it's own error "event is not defined", keeping the code from even reaching the 'deslect' method call. But it begs the question. If I've neither added an element nor changed any of their positions, why do I need to call refresh? There shouldn't be anything magic going on here. The plugin makes it easy to add the ui-selected (for semantics) and ui-state-active (for visual feedback) classes to elements using the keyboard and mouse. If items matching filter have those classes, they *are* selected.

It seems the "event is not defined" is a FF3.5 issue on Windows. Haven't tested other OSes, but can't reproduce in IE6, Chrome, Safari, or Opera.

Paul Bakaus said

at 11:26 am on Aug 28, 2009

Yeah, maybe we can change the logic to support the class changes from the outside - yet, I would honestly prefer if people simply call the select method, since it would be a lot easier. I actually have to keep an array of selected items internally for performance reasons.

Richard D. Worth said

at 11:45 am on Aug 28, 2009

might be as simple as calling refresh method first thing inside of select and deselect methods

Richard D. Worth said

at 10:14 am on Aug 27, 2009

It sounds like yours is an issue with ensuring a valid selection, which I don't think should be achieved by limiting the accessibility options the user has to make selections. One way to handle this would be the recommendation I have above that start, select, and deselect events should be cancelable. In this case, you could detect what selection the user is trying to end up with, either by keyboard or mouse, ensure it is valid (in your case, contiguous elements in DOM order), if it's not, return false and it will be prevented. This would allow the user the hold down the shift key and press the right arrow 5 times to make the same kind of valid selection they can with the mouse lasso. But it would prevent them from using ctrl+arrow, ctrl+space or ctrl+click to make non-contiguous (which in your case is non valid) selections.

Jaggi said

at 3:22 am on Aug 28, 2009

this probably wouldn't work for me as at the moment i'm using a table grid which has multiple rows/columns and they can make any selection as long as its in a square/rectangle order. I'm sure with enough coding and fiddling i could make it work how your saying but that doesnt' necessarily merit doing it that way. Using a lasso is restricted to a rectangle/square box which gives the users a visual representation of what they're doing rather than the keyboard shortcuts which don't, i much prefer to give the user these visual representations than making use of backend "magic" such as shortcuts. Its very easy to disable shortcuts as most users won't miss them and provide a fool proof way of doing. also most web users and numb and telling them to shift click/ctrl click to make selections but not allowing it to work in certain circumstances will just confuse them rather than provide them any useful user experiance.

Richard D. Worth said

at 4:43 am on Aug 28, 2009

Using the keyboard instead of, or in addition to the mouse is not just about keyboard shortcuts. I'ts about having fully accessible plugins, which is one of the main goals of jQuery UI. There is a not insignificant body of users that are comfortable using the keyboard, or even *only* able to use the keyboard. Though it isn't implemented yet, I think we should support drawing a 4x3 rectangular lasso (that keeps selections valid in your case), with the keyboard, by holding shift and pressing down-down-right-right-right, just as you can in a spreadsheet. That's probably a fitting analog, since you're talking about a table grid with multiple rows/columns and rectangular selections. Does the select interaction that a spreadsheet provides match your needs?

Jaggi said

at 10:45 am on Aug 28, 2009

yes that would work however i don't see the point it, i'd have to write a load more code just to check the users keyboard input is valid. ita kinda of defeats the purpose of having it ready out the box.

Richard D. Worth said

at 11:03 am on Aug 28, 2009

If there were built-in support for doing a rectangular selection using the keyboard, the users would have the same capability the mouse lasso gives them. Beyond those two selection modes, it sounds like you have a need to limit the user to one contiguous selection? If that's the case than when a new selection starts, clear the old one. I don't see anything to build into the plugin here, other than an appropriate event that you can handle in a custom fashion. This was never the design of the keyboard:false option.

Richard D. Worth said

at 11:05 am on Aug 28, 2009

Hmm, contiguous suggests dom order. I meant to say you want the user to only select one rectangle, right? Otherwise ctrl+click, ctrl+click, ctrl+click three items that are nowhere near each other would mean three 1x1 rectangles.

Richard D. Worth said

at 11:13 am on Aug 27, 2009

I agree that's a valid use case, but I prefer alternatives to a built-in boolean option called 'keyboard'. Here are a couple:

* Have your individual selectable items handle these key events in a custom way and prevent them from bubbling to the selectable container. Just as "select and drag" lets you drag a lasso to select items and then drag those selected items to move them, even without needing to turn off mouse selection, "select and arrow" shouldn't require turning off keyboard selecting.

* If you don't want to do it at the item level, but instead do event delegation on the selectable container, the start event could be cancelable. Inside it, check the type of event.originalEvent. If it's a key event and an arrow key was pressed, return false, and do the custom key handling outside this plugin.

Richard D. Worth said

at 11:14 am on Aug 27, 2009

I've got another idea about how we could combine these options (alternate keyboard handling and dom order selecting vs. location selecting). We could have a keys option, where you could specify callbacks for each arrow keypress as overrides. Example:

$("#selectable").selectable({
keys: {
up: function() { $(this).selectable('focus', 'prev'); },
right: function() { $(this).selectable('focus', 'next'); },
down: function() { $(this).selectable('focus', 'next'); },
left: function() { $(this).selectable('focus', 'prev'); },
}
});

so that would be dom order, since we're doing prev and next. If instead you wanted to do by relative position:

$("#selectable").selectable({
keys: {
up: function() { $(this).selectable('focus', 'up'); },
right: function() { $(this).selectable('focus', 'right'); },
down: function() { $(this).selectable('focus', 'down'); },
left: function() { $(this).selectable('focus', 'left'); },
}
});

Or maybe that method call would be 'select' instead of 'focus', but anyway. This would be an alternative to the current boolean option 'closest', which I don't think conveys well enough in name what it does when true or false.

Richard D. Worth said

at 11:15 am on Aug 27, 2009

Some shortcuts could be:

keys: { up: false, right: false, down: false, left: false } // don't capture arrow key events
keys: { up: 'prev', right: 'next', down: 'next', left: 'prev' } // select by dom order
keys: { up: 'up', right: 'right', down: 'down', left: 'left' } // select by layout

Or, if you're not crazy about the idea of a hash option (I'm often not), these could be top-level selectable options:

$('#selectable').selectable({ up: fn, right: fn, down: fn, left: fn });
$('#selectable').selectable({ up: false, right: 'next', down: false, left: 'prev' });
$('#selectable').selectable({ up: 'up', right: 'right', down: 'down', left: 'left' });

Paul Bakaus said

at 11:05 am on Aug 28, 2009

I like those shortcuts. Make the whole thing really flexible.

Richard D. Worth said

at 7:42 am on Sep 3, 2009

Now that I've proposed separating arrow navigation from selection modes, clarifying and standardizing both, I no longer think we should pursue this option. See http://groups.google.com/group/jquery-ui-dev/browse_thread/thread/3073dd8a2f7c5f40

Richard D. Worth said

at 8:03 am on Aug 28, 2009

The static demo still needs to updated to illustrate the outline that a focused selectable item should have. Thanks.

Todd Parker said

at 8:52 am on Aug 28, 2009

We need to modify the ThemeRoller generated stylesheet to remove the rule that negates the browser's default focus outline for the static demo to look right. Currently in theme.css, we have a rule for ui-state-hover and ui-state-focus that sets the outline to none. We need to remove that rule and hope that this doesn't introduce any issues elsewhere. By leaving the outline styles alone, the browser can figure out what color to set the outline based on it's own contrast rules. Scott J. is looking into committing this now.

Jaggi said

at 3:44 am on Sep 1, 2009

yea doing it that way would work too i guess and yes i would only like one rectangle to be selected as i rely on this in my other code.

Jaggi said

at 3:53 am on Sep 16, 2009

think i've found a bug for this in IE, when you click a element it jumps to focus to the top of the parent element this is however a bug as for example if you have a small work area (800x600) it'll move the clicked element out of view which is obviously not a desired behaviour. It should probably focus on the clicked element or do as firefox and just not move out of view of anything.

Eric said

at 11:05 am on Mar 11, 2010

Why does the style for the helper is in the html page and not inthe style sheet file like on all other widjets?

Paul Bakaus said

at 11:25 am on Mar 11, 2010

Are you talking about the current version, or the version that is being rewritten ( in labs)? I suspect you mean the current version, and by helper you mean the lasso. Indeed it was a design flaw to have the dotted outline as fixed style applied in the helper. This is fixed in the new labs version.

Richard D. Worth said

at 11:25 am on Mar 11, 2010

The current version of selectables simply adds a ui-selected class, no jQuery UI CSS Framework classes. This is acutally consistent with existing interactions vs. widgets with the exception of resizable. Draggable doesn't add framerwork classes, nor does droppable or sortable. The refactor of selectables that's in-progress will use framework classes such as ui-state-active and ui-state-focus.

Carl Fürstenberg said

at 4:07 pm on May 1, 2010

For ctrl and shift click, here is an code snipped I made for an unrelated code, that might be useful for you: http://gist.github.com/386655
I don't use index() here as I didn't know back then I could use it for tables :)

Carl Fürstenberg said

at 4:10 pm on May 1, 2010

though ignore the "was_shift_key" as it's just an artifact I seems to forgot to remove :)

atovstonog said

at 6:46 am on Aug 12, 2010

If it's possible to provide selectable styling through the ThemeRoller? Here(http://jquery-ui.googlecode.com/svn/branches/labs/selectable/demos/selectable/default.html) styles that made selected item orange etc. are defined directly on page. So for any another theme, from ThemeRoller, I should use another file with "selectable" styles, and it's not useful as for me. It will be much more better if ThemeRoller will create styles for "selectable" too.

Drew said

at 3:23 pm on Aug 20, 2010

Not sure if this has been brought up but I don't think ctrl+shift+click is working as expected.

Richard D. Worth said

at 3:45 pm on Aug 20, 2010

In the current (stable) version, or the refactor?

Drew said

at 7:18 am on Aug 23, 2010

On http://jquery-ui.googlecode.com/svn/branches/labs/selectable/demos/selectable/default.html ctrl click 1, ctrl click 2, ctrl click 5, ctrl+shift click 7. I would normally expect 1-2 an 5-7 to be selected, not 1-7.

phazei said

at 7:16 pm on Aug 26, 2010

If a non-selected item is active, you can tell because it's grey. But there is no indication that a selected item is active. This is an issue when using the keyboard and everything is selected and the ctrl key is pressed. If you move up and down, the selected items get no new highlighting so you can't tell where you are.

Yoann said

at 5:29 am on Oct 18, 2012

Is there any plan to integrate the shift range selection in a stable release ?

lukaszb said

at 7:32 am on Apr 11, 2014

Proposal: selectedItems/unselectedItems events that would include all items being selected/unselected.

Motivation: when user stops selecting items I need to check what items exactly was selected. I can store state on start, then check what has changed on stop. Or I could try to listen to selected/unselected events for each items separately. Both workarounds require me to compare states at some point. With proposed events that passes arrays of selected/unselected items (all at once) I wouldn't have to store state at all.

Let me know if that makes sense to you.

Original Pull Request: https://github.com/jquery/jquery-ui/pull/1220

You don't have permission to comment on this page.