Dropdown menus should overlay scrollable areas

[ConradSchmidt]

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 Modal overflow #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.

[PaulJThompson]

@emyarod @ConradSchmidt I don't see how this could be considered an enhancement and not a defect. This issue also impacts Cognos Analytics (CA). Please reconsider it as a bug.

[andreagmann]

This is a defect that impacts all of CPD. Some devs have been able to add margin/padding to the table or modal to somehow alleviate the problem, but it deviates from the design and should obviously be addressed at the component level instead.

[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:

Screen.Recording.2021-02-26.at.15.59.57.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]

@joshblack as a good starting point, https://carbondesignsystem.com/components/overflow-menu happens to be found in the same tables where inline dropdown is found but handles boundary cases in a better way. It can be mirror-flipped and also tends to avoid being clipped by the nearest parent. Any chance overflow menu already has some of the remedies needed here?

[joshblack]

@dglozic oh definitely, great example. Another similar option available now for teams running into this could be to use the direction prop to specify that the dropdown menu should open upwards instead of downwards.

In terms of auto-detection like in OverflowMenu, it's definitely something that we would like to add in since the check doesn't seem too bad and positioning isn't too hard if the item is placed in-context 👍

[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.

[WilliamHolmes]

I remember having this issue some time ago (not using carbon at the time). This library was useful tether
BTW I've also seen this issue with menu overlay on the Enhanced data table filters etc. when the table only had a single row, enough for the menu drop down to go underneath.

[tay1orjones]

Going to close this since it seems we found a few reasonable ways to address this - direction, external lib (tether, etc). We can always reopen if there's more to address.

[dglozic]

@tay1orjones I don't see how we found reasonable ways to address this. For example, direction will not help with the bottom cutoff, or when the overall vertical space is smaller than needed by the dropdown (which is happening today in Cloud PAL in EnhancenedTable, for example). I also don't see how tether.io helps with Carbon - @WilliamHolmes in which way does an external utility help with this particular problem?

[WilliamHolmes]

I believe tether binds components (in this case a popup menu) placed in the body tag and position them around a target.
This would mean that the popup can be placed over any other component on the page. Tether is just an option worth investigating, however i don't know how accessible the UI components are in relation to screen readers etc.

[wkeese]

As @joshblack mentioned, attaching the dropdown to <body> solves the clipping problem, but is problematic for virtual cursors, like VoiceOver on iOS.

As I wrote in #9732, the way to have your cake and eat it too is to stop setting position:relative on nodes between the dropdown and the node that scrolls. It's not trivial to do that though.

In the example linked above:

• wkc-add-modal__list-wrapper, bx--structured-list-td, and bx--list-box--inline switch to position:static
• bx--list-box__menu gets set to top:550px. Obviously that's a computed value, and your number may vary. We are using https://github.com/ibm-js/delite/blob/master/place.js to set it.

[tay1orjones]

Reopening based on the previous #7565 (comment) above that there are some options that can be looked into.

I think this can also apply to areas with overflow: hidden in addition to the original request of areas with overflow: scroll

That said, this thread contains quite a few other options to pursue if you're running into this problem.

[wkeese]

I remember having this issue some time ago (not using carbon at the time). This library was useful tether... I believe tether binds components (in this case a popup menu) placed in the body tag

To be clear, attaching to <body> is what breaks VoiceOver. (FWIW, I also used to think attaching to <body> was a good idea, before the days of supporting accessibility on mobile.)

[tay1orjones]

One additional workaround for this is to use Select instead of Dropdown. I know it's not ideal, but for the simple use case of selecting item(s) from a list, this will properly overlay modal areas.