Closed phidias51 closed 8 years ago
paper-menu
is designed for e.g. website navigation and such, where persistent-selection id desired. It sounds like you're describing a what would amount to effectively a different element to provide behavior ala desktop menuing (File, Edit, View, etc. menus) -- that's a valid use case also, it's just different than what this element was designed for.
Please feel free to file element requests at https://github.com/polymerelements/paper-elements/issues
I guess if that's the case, then it would be better to give it a navigation-related name (i.e. "paper-nav-menu"), and document that it's to be used for navigation only. That said, according to the material design spec:
A menu is a temporary piece of material emitted from a button, an action, a pointer, or another control that contains at least two menu items.
Each menu item is a discrete option or action that can affect the app, the view, or selected elements within a view.
Menus should not be used as a primary method for navigation within an app.
This description seems more in line with what I was saying about menu item selections not persisting (but being discrete options) and not being used for navigation. Also, most of the existing examples in the spec fit my earlier description of menu behavior.
The paper-item remains selected after the menu closes. This means a user cannot select the same menu item later in their session. For example, one could imagine a menu with the typical cut/copy/paste menu items. In a word processing application like Google Docs, you'd want to be able to use these menu items multiple times during an editing session.
By default the menu should allow you to select the same menu item multiple times. This is the standard way that menus work in every windowing toolkit. If you want persistent menu item selections (such as with checkbox or radio menu items), then this should be an option, but not the default.