Migrate block options menu to DropdownMenu v2 and use flyout menus to re-organise actions

[jameskoster]

What problem does this address?

We've added a lot of items to the block options menu. It's become a bit unwieldy and it's not uncommon to encounter a scrollbar which buries frequent actions:

options.mp4

What is your proposed solution?

Adopt DropdownMenu v2 and utilise flyouts to reduce its initial footprint and better organise actions.

[richtabor]

We also have "Select parent block (blockName)" to account for. I'm thinking it shouldn't displace the other items in the common actions. Perhaps append to the end of the common actions?

[alexstine]

Left some feedback on the linked PR.

• Changing remove to delete makes sense.
• Delete blocks is too trivial for non-sighted users. Sighted users can see what is currently selected in the canvas.
• Up until now, I thought you could only access the block toolbar if one block was currently being edited. I had little idea that the block toolbar was still available to use for multiple blocks.
• Due to how hard it currently is for non-sighted users to tell what is selected outside of the toolbar, it would be nice to provide that context somehow that the toolbar will take action on all selected blocks including X, X, and X.
• This would be where I would highly prefer a right click context menu for these things. It was ultimately shot down for the list view.
• It makes sense to keep delete in the last group at the end of the menu for quick access with up arrow key.

I am not sure this discussion needs to happen over delete blocks or the entire toolbar itself. Likely the toolbar. That way we can provide some type of description on the toolbar to let users know the controls apply to the selected blocks. Might be good for a follow-up PR since all of this is being discussed currently.

[richtabor]

In all, we're a bit in the weeds—but forward progress; love it.

The big blocker here is the flyout type component. @alexstine what are your thoughts on flyouts (or submenus) in this use case. Do you have examples, or other libraries, that leverage accessible submenus in UI well?

Like the Radix DropdownMenu component for example.

[richtabor]

Do we still need this? The paren't selector seems like a more convenient affordance, but I'm not familiar with the history.

I don't think we do.

[alexstine]

I am not familiar with any 3rd party libraries that have out of the box accessible components. Most React/Vue libraries are junk for accessibility. Any reason we're not going to develop this in wordpress/components?

Happy to check any examples but I will set expectations now.

Thanks.

[richtabor]

Any reason we're not going to develop this in wordpress/components?

Likely will, though I would like to start off with good examples to work from if possible.

[alexstine]

@richtabor I am having a really hard time coming up with any ARIA specifications for flyout menus. If it helps, the flyout menu for Google Drive is perfectly accessible. Other than that, I think we'll have to just see what works. I am kind of interested to see if there are any accessible examples out there but I am coming up empty.

@joedolson You know of any good material on this?

Thanks.

[jameskoster]

I've updated the design in the OP based on discussion, and will mark comments as outdated. Agree the design is in a decent place as a starting point.

The one detail missing is whether or not we still need the Select parent action. I think it predates both List View and the dedicated parent selector affordance, which both feel like more convenient ways to select the direct ancestor, hence the removal. What do y'all think?

[alexstine]

@jameskoster Where is the dedicated select parent located?

[ciampo]

Any reason we're not going to develop this in wordpress/components?

We are indeed looking into adding support for nested dropdown menus, but as @richtabor also explained, it's good to start exploring our usecases and let that help us to make the right decisions.

It's very likely that we'll resort to a third party library, since this pattern is quite complex and difficult to get right, and there's no need for us to reinvent the wheel. Hopefully we'll find a good solution that is accessible, fits our needs, and at the same time works with all the constraints of the editor (the biggest one that comes to mind is syncing position updates across the iframe).

I hope we'll be able to share updates within the upcoming weeks.

[alexstine]

Oh, the iFrame. That will be interesting for sure. Still having a really hard time getting basic functionality to work in it across all screen readers. See #47767 for more context. I urge us all to really take our time in testing. I am a screen reader user and not testing on both platforms came back to haunt me there.

[jameskoster]

@jameskoster Where is the dedicated select parent located?

@alexstine it's the first item in the block toolbar, titled 'Select [block name]'.

[alexstine]

@jameskoster Awesome. No need to keep it in the more menu then.

[richtabor]

We are indeed looking into adding support for nested dropdown menus

Here's another use case for supporting nested dropdowns: #40208

[richtabor]

@ciampo do we have/need an issue separate for the nested dropdown? And is there an update on that front perhaps? Thanks!

[ciampo]

@ciampo do we have/need an issue separate for the nested dropdown?

We didn't, but I just created one: #50459

And is there an update on that front perhaps? Thanks!

I plan on releasing a very experimental, initial version of the component in the next days. It will still need tweaking and lots of testing in the editor, but hopefully we'll get there quickly enough

[richtabor]

I plan on releasing a very experimental, initial version of the component in the next days. It will still need tweaking and lots of testing in the editor, but hopefully we'll get there quickly enough

Very cool!

[mtias]

Where are we on this?

[jameskoster]

The proposed organisation is still welcome to feedback. DropdownMenu v2 is available (providing access to flyout menus) so I think this is ready for a PR.

[ciampo]

• The component itself, in terms of features, is basically ready and only needs potential tweaks;
• Its APIs need a few tweaks, which will be a breaking change (although that's fine because it's still private)
• Its usage for the block toolbar dropdown is a work in progress. The integration of this component is tricky, as it's full of unknowns re. how the component integrates with the editor (including things like modality of the dropdown and dialogs that open on top of it, anchoring with the toolbar outside of the iframe, integration with slot/fills where third party consumers may inject v1 menu items, etc). I already went through many of those wrinkles and I plan on continuing to do to. I had many attempts at integrating the v2 dropdown menu already, the last draft PR is Block Editor Settings: use v2 DropdownMenu #57996. I will resume work on it shortly after any high-priority 6.7 stuff is addressed.