A menu based on icon + label options seems a common pattern to standardise. When I designed some of the menus I took for granted that such a component already existed (aren't menus on toolbars already using such pattern?).

In terms of the specific styling I'd keep it closer to the current menus we have for toolbars:

• I'd not include a separation line between all options. That would make it consistent with the toolbar menus and would allow to have a special "separator" element that can be used to create groups of actions in the menu ( as in the flow case).
• I'd avoid the triangle, and instead highlight the element that opened the menu. Seems a simpler approach (less elements involved) and is consistent with the toolbar menus, but I'd be ok to use the triangles if we decide to go in that direction.

aren't menus on toolbars already using such pattern?

Yes, but toolgroups can only exist within full toolbars.

In T178387#3726141, @Esanders wrote:

aren't menus on toolbars already using such pattern?

Yes, but toolgroups can only exist within full toolbars.

Ok. I was expecting those to be easer to reuse. In any case, leaving the technical aspect aside I think it makes sense to keep menus consistent in both cases, inside toolbars and outside them.

Agreed, standardising vertical popup menus in tune with the toolbars makes sense.

In T178387#3725715, @Pginer-WMF wrote:

• I'd avoid the triangle, and instead highlight the element that opened the menu. Seems a simpler approach (less elements involved) and is consistent with the toolbar menus, but I'd be ok to use the triangles if we decide to go in that direction.

I agree. We might also need to standardise our vocabulary for "there is a menu here" when no particular context like Settings (in Echo) is available. We are already using the icon for this, but might work too. I am happy with either, just that we need to keep in mind to be consistent. Applies to T175953: OOUI: Support Responsive Toolbars too (the icon, not vertical popup, since its already a toolbar).

@Esanders, are we looking to add something like a MenuButtonWidget?

@Mooeypoo You've also been looking into this element currently in the Structured Discussion work, correct?

This would also apply to the topic bar in Flow:

I'm thinking this could be done with some small changes the DropdownWidget, such as making the handle frameless, and not changing the label when an item is selected.

Experimenting, one of the problems is DropdownWidgets clip the menu width to the same size as the handle width. We need a dropdown that behaves more like a menu tool group.

In T178387#4126616, @Esanders wrote:

We need a dropdown that behaves more like a menu tool group.

Filed as T195257

To add to the list, we have this also in RCFilters:

And in the full-screen map sidebar (the icons were hacked to display on the right, but it's again the same vertical group of buttons)

In T178387#4121263, @Esanders wrote:

I'm thinking this could be done with some small changes the DropdownWidget, such as making the handle frameless, and not changing the label when an item is selected.

Maybe, but that won't solve for cases where we need that list static rather than a dropdown appearing/disappearing functionality, like in the maps sidebar.

That ties into having, in general, a non-disappearing "menu" behavior like a better implemented OO.ui.SelectWidget rather than haing to use and then tweak the base behavior. The problem with the SelectWidget is that if you want button behavior (and not a select) it's trapping mousedown/click events, but the idea of having a vertical list of either choos'able stuff (select widget) or clickable stuff (button group) should be solved for, and hopefully for the case of a non-menu / non-disappearing dropdown too.

That ties into having, in general, a non-disappearing "menu" behavior like a better implemented OO.ui.SelectWidget

I think OutlineSelectWidget / OutlineOptionWidget, although named as if it can only be used in a BookletLayout is actually very suitable for these static list scenarios.

We may want to create a parent classes that have a more generic names, and removes some of the methods only called by OutlineWidget (e.g. move/remove), but for now it should be perfectly usable.

In T178387#4221990, @Mooeypoo wrote:

To add to the list, we have this also in RCFilters:

(Though to be fair, we had to extend the functionality there a bit to have sub-menus and to have an "edit" capability, but the base is still a vertical group of buttons)

Those sub menus definitely need some work. Having nested dropdowns doesn't seem like a great UI.

In T178387#4222018, @Esanders wrote:

That ties into having, in general, a non-disappearing "menu" behavior like a better implemented OO.ui.SelectWidget

I think OutlineSelectWidget / OutlineOptionWidget, although named as if it can only be used in a BookletLayout is actually very suitable for these static list scenarios.

We may want to create a parent classes that have a more generic names, and removes some of the methods only called by OutlineWidget (e.g. move/remove), but for now it should be perfectly usable.

The issue with any SelectWidget is that we count on the things in it to be selected with events, so we trap a lot of mouse events and emit 'select' and 'choose'. This is fine for when that's the behavior needed, but in some cases, like Echo's list of notifications or the map sidebar, the click should act like a link - open notification (or the map link) and allow for right-click to open the link in a new tab. We can't really do that well with a SelectWidget unless we override the multitude of event trapping it does.

Also, SelectWidget, since it assumes it's used to, well, select stuff, is hard to adjust to use sub-functionality. for example, in Echo's items, you have the "main" click event (go to the notification source) but also a few sub-buttons, like go to the user page that originated the notification, or go to the discussion thread, etc etc. In a SelectWidget/OptionWidget scenario, you need to override a whole bunch of capturing click events so that we allow for "sub" buttons.

In RCFilter's Saved Filters for example, even if we get rid of the sub-menu (which I agree is not good) we'll need to sort out some way of edit/delete/etc the items. We could add icon buttons to the end of each item, but, again, that would mean we have a clickable "thing" in a widget that captures click events (if we use SelectWidget-like stuff)

So... I don't know if the overall solution of a SelectWidget when we need lists-of-stuff-with-clickable-things-in-them is the best one.

Change 434486 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/Echo@master] Convert SpecialHelpMenuWidget to a customised DropdownWidget

https://gerrit.wikimedia.org/r/434486

In T178387#4222051, @Mooeypoo wrote:

The issue with any SelectWidget is that we count on the things in it to be selected with events, so we trap a lot of mouse events and emit 'select' and 'choose'. This is fine for when that's the behavior needed, but in some cases, like Echo's list of notifications or the map sidebar, the click should act like a link - open notification (or the map link) and allow for right-click to open the link in a new tab. We can't really do that well with a SelectWidget unless we override the multitude of event trapping it does.

See the above patch to Echo. $( '<a>' ).attr( 'href', '...' ) can be passed to $element in the config, giving you right/middle click functionality, and normal selects can be handled with location.href. This could be packaged into a LinkMenuOptionWidget, and handled upstream. The CX user menu does something similar.

Also, SelectWidget, since it assumes it's used to, well, select stuff, is hard to adjust to use sub-functionality. for example, in Echo's items, you have the "main" click event (go to the notification source) but also a few sub-buttons, like go to the user page that originated the notification, or go to the discussion thread, etc etc. In a SelectWidget/OptionWidget scenario, you need to override a whole bunch of capturing click events so that we allow for "sub" buttons.

In RCFilter's Saved Filters for example, even if we get rid of the sub-menu (which I agree is not good) we'll need to sort out some way of edit/delete/etc the items. We could add icon buttons to the end of each item, but, again, that would mean we have a clickable "thing" in a widget that captures click events (if we use SelectWidget-like stuff)

So... I don't know if the overall solution of a SelectWidget when we need lists-of-stuff-with-clickable-things-in-them is the best one.

Nested click areas are a bad idea to begin with, so it's not surprising that you need to do some overriding to support this. I wouldn't want to make it easier for people to build UI's like this.

I'm very happy about this collection and the general take on the task so far. Want to throw shortly in, that we should decide and (probably) unify visual appearance of the menus, going for either a menu (CX example) or a rich tooltip appearance (Echo example).

In T178387#4222188, @Esanders wrote:

See the above patch to Echo. $( '<a>' ).attr( 'href', '...' ) can be passed to $element in the config, giving you right/middle click functionality, and normal selects can be handled with location.href. This could be packaged into a LinkMenuOptionWidget, and handled upstream. The CX user menu does something similar.

Hmm, I see. I am still a little suspicious here; SelectWidget captures a ton of mouse events, for example

OO.ui.SelectWidget #57-60

	this.onMouseUpHandler = this.onMouseUp.bind( this );
	this.onMouseMoveHandler = this.onMouseMove.bind( this );
	this.onKeyDownHandler = this.onKeyDown.bind( this );
	this.onKeyPressHandler = this.onKeyPress.bind( this );

OO.ui.SelectWidget #69-74

	this.$element.on( {
		focusin: this.onFocus.bind( this ),
		mousedown: this.onMouseDown.bind( this ),
		mouseover: this.onMouseOver.bind( this ),
		mouseleave: this.onMouseLeave.bind( this )
	} );

And last I tried to use the widget, those interfered pretty badly. I think it was mostly when I had other clickable things in there (like a sub menu, or a separate button in the OptionWidget, though)

Either way, this seems to be working, so I might be wrong, but I'll keep an eye out to re-discover the cases that I had so much trouble with last time, I'll give them as actual examples if I get them again so we can solve for those specifically.

Nested click areas are a bad idea to begin with, so it's not surprising that you need to do some overriding to support this. I wouldn't want to make it easier for people to build UI's like this.

They might be bad for a select widget, but I don't think they're inherently bad. Echo's notification structure makes sense even with the different clickable stuff -- we might want to make sure that in these cases there's a clear clickable are and the menus/buttons are outside of it or under it, but we can't do that with a pure (or extended) OO.ui.OptionWidget if that widget assumes the entire area is one big clickable element.

In a conversation, @Pginer-WMF and myself tried to find a balance when to use a callout triangle. Our proposal:
Whenever a popup replaces a dialog, it should have a callout triangle. All of the above showed examples are on the menu side, so shouldn't feature a triangle.

In T178387#4228563, @Volker_E wrote:

In a conversation, @Pginer-WMF and myself tried to find a balance when to use a callout triangle. Our proposal:
Whenever a popup replaces a dialog, it should have a callout triangle. All of the above showed examples are on the menu side, so shouldn't feature a triangle.

Sorry... what do you mean with a "callout triangle" ?

@Mooeypoo Hehe, MobileFrontend were the last to rename it internally due to confusion. Didn't they call it “pokey” – which didn't clarify anything for me non-native English speaker. Were referring to the UI triangle element pointing at the drop-down/menu initiating element.

Change 435783 had a related patch set uploaded (by Esanders; owner: Esanders):
[VisualEditor/VisualEditor@master] VWIP Table context to dropdown

https://gerrit.wikimedia.org/r/435783

Change 434486 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Convert SpecialHelpMenuWidget to a customised DropdownWidget

https://gerrit.wikimedia.org/r/434486

Another small issue to address with using the DropdownWidget is that we probably want to use button appearance for the handle, which is only really an issue for Apex:

That said I think sub-classing DropdownWidget (MenuDropdownWidget?) is probably going to be the best approach...

@Esanders Or we could amend Apex dropdowns to become button-like 3D gradient per default similar to WikimediaUI and other interface themes.

Change 588011 had a related patch set uploaded (by Esanders; owner: Esanders):
[oojs/ui@master] Implement ButtonMenuSelectWidget

https://gerrit.wikimedia.org/r/588011

Change 588011 merged by jenkins-bot:
[oojs/ui@master] Implement ButtonMenuSelectWidget

https://gerrit.wikimedia.org/r/588011

Change 588826 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Update OOUI to v0.38.0

https://gerrit.wikimedia.org/r/588826

Change 588826 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.38.0

https://gerrit.wikimedia.org/r/588826

Change 588983 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/Echo@master] SpecialHelpMenuWidget: Use ButtonMenuSelectWidget

https://gerrit.wikimedia.org/r/588983

Change 589012 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/core@master] RCFilters: Use ButtonMenuSelectWidget for SavedLinksListWidget

https://gerrit.wikimedia.org/r/589012

Change 588983 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] SpecialHelpMenuWidget: Use ButtonMenuSelectWidget

https://gerrit.wikimedia.org/r/588983

Change 589012 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Use ButtonMenuSelectWidget for SavedLinksListWidget

https://gerrit.wikimedia.org/r/589012