Dropdown menus should overlay scrollable areas

Summary

If a dropdown is used within a scrollable area they will be cut off by the surrounding container. This leads to broken layouts or even actions impossible to access. Example (dropdown hidden by scrollable area and actions can’t be accessed): Try it here (IBM internal)

Currently only the DatePicker supports an appendTo option, which would solve this issue. This issue can’t be resolved from the outside (css, add-ons, js, …) - only the Carbon components itself can fix this issue, that is why it is so hard to deal with.

Justification

This issue occurs in several products:

• Watson Knowledge Catalog (WKC)
• Cloud PAK for Data (CPD)
• Also covered in this Slack discussion
• And other (see https://github.com/carbon-design-system/carbon/issues/6288)

Desired UX and success metrics

The dropdown should overlay the scrollable container.

“Must have” functionality

The dropdown should overlay the scrollable container (see above).

Specific timeline issues / requests

As soon as possible, because there features which should be shipped by begin of February. Currently the design is asked to design around this issue, which shouldn’t be the case.

NB: The Carbon team will try to work with your timeline, but it’s not guaranteed. The earlier you make a request in advance of a desired delivery date, the better!

Available extra resources

What resources do you have to assist this effort?

Modal with dropdown issue(IBM internal) Dialog appendTo plugin Existing issue

Carbon is a collaborative system. We encourage teams to build components and submit them for integration as either add-ons or core components.

[joshblack]

@PaulJThompson @andrea-gm for context as to the label, most likely this is flagged as an enhancement as it would be a nontrivial change to the component itself and would need coordination with parent components in order to be accessible.

Currently, the menu renders in-context in the current DOM tree which is what causes the layout shift to happen the way that it does. In order to break out / overlay the container, it would need to be rendered in portal / outside of the existing DOM tree.

Unfortunately, this creates accessibility implications with respect to the menu. Since the menu no longer resides in DOM order, when the user interacts with it using a virtual cursor they can become lost on the page. It also can be problematic with dialog patterns as focus is supposed to remain trapped inside of the dialog. Here’s a quick example using Airtable that demonstrates this behavior:

https://user-images.githubusercontent.com/3901764/109360108-3f503200-784c-11eb-91bf-ed4f6b412ca4.mov

In this demo, I use VoiceOver’s virtual cursor to move to the end of the menu, then back to the beginning. When traversing before the menu you see that it has lost the position on the page. Similarly, when going to the end of the group and going up a level it will go to the webpage root. This makes it difficult to “get back” to where a user was in the dialog.

IBMa has provided some recommendations in this space over on Slack that we can investigate adding. I would assume this work would require:

• The caller to provide aria-owns on the parent element that corresponds to the menu id
• Accepting a menuId prop so that the caller can pass in the menu id to the dropdown
• Allowing the menu itself to be rendered in a portal and calculating the correct positioning of it relative to the trigger element

Another path that we can go down is to see if we can figure out what direction the menu should open, or provide an option for developers to specify that direction, as an alternative scheme here if that’s helpful 👍

I hope this is helpful with articulating where the component is right now, what challenges we may have, and what solutions we can consider moving forward. I’d be happy to sync up with any teams looking for this kind of functionality to figure out next steps, just let me know!

[dglozic]

Right, I have not seen as many people complaining about OverflowMenu, which means that in practical use they tend to handle the floating panel with items in a decent way. I am mentioning it because it is an existing Carbon component so copying over its logic may be easier than devising something entirely new for dropdown menus.