Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for PR: add "traditional" multi-select to iron-selector #123

Open
Caffeinix opened this issue May 10, 2016 · 4 comments
Open

Proposal for PR: add "traditional" multi-select to iron-selector #123

Caffeinix opened this issue May 10, 2016 · 4 comments

Comments

@Caffeinix
Copy link

I have written an extension to IronMultiSelectableBehavior that implements a more general and traditional form of multi-select, similar to how multi-select works in most desktop applications. The behavior is as follows:

  • Tapping an unselected element with no modifier selects it and deselects all other elements.
  • Tapping a selected element with no modifier deselects all other elements.
  • Tapping an element while holding shift selects all elements between it and the most recently selected other element, inclusive, and leaves all other selected elements alone.
  • Tapping an unselected element while holding control or command selects it and leaves all other selected elements alone.
  • Tapping a selected element while holding control of command deselects it and leaves all other selected elements alone.

My implementation is small (43 source lines) and works by extending IronMultiSelectableBehavior and overriding two functions, _activateHandler and _toggleSelected. The _activateHandler implementation just records the keyboard modifiers and then calls IronMultiSelectableBehavior's version. _toggleSelected is where the actual logic is implemented.

My implementation does not support a "mixed" mode where an unmodified tap will toggle the selection state like IronMultiSelectableBehavior, but a shift-click will extend the selection. Such a thing would be relatively easy to add if it were desired, but it would increase the complexity somewhat.

This PR would fix #38.

Thoughts?

@bicknellr
Copy link
Contributor

I think this would be really awesome! We might have to go with the "mixed" mode you mentioned as the default since we'd be introducing a breaking change otherwise, but allowing the regular <select multiple> style wouldn't be a problem if it was behind a property.

@yarikus
Copy link

yarikus commented Sep 13, 2016

Where I can to get your extension? Please share it with community.

@timoteoponce
Copy link

Where can we get a preview of this extension to test it?

@czellweg
Copy link

@Caffeinix Awesome, I'd be interested to look at this code as well. Can you share it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants