Dropdown can not work well inside a container 'overflow'

[matuzalemsteles]

The current Dropdown that we have it identifies only the size of the screen to know which position will position itself. In more complex environments such as table, your element uses overflow-y:hidden it can not identify that your view will be overridden. This becomes a problem in order to use it.

[yuchi]

Alloy UI drop downs used to attach the menu directly on the body and using a z-index stack manager to (try to) ensure its visibility.

In metal and ICD there's no concept of portals AFAIK (see React docs about them) and it could prove a little difficult to extract the menu in a different part of the dom.

[yuchi]

Also, boostrap-style drop downs (those that just show/hide in place) are terribly easier to implement a11y-wise.

If we go back to portal-style menus we'd also need to obscure the page until the menu is closed.

[carloslancha]

Hey @matuzalemsteles where do we have the overflow: hidden?

[matuzalemsteles]

Table is used in the class table-responsive for using when viewing in the mobile. @pat270 You can talk more about it.

[carloslancha]

http://pat270.github.io/lexicon/content/tables/

There it's being used table-responsive-lg or table-responsive-sm, why with those dropdown is not affected? Anyway what @yuchi pointed is true, we need to do it in a way to use dropdown in place (like we're doing right now). Maybe we should avoid this kind of overflow issues...

[pat270]

This has been a long standing issue with dropdowns in responsive tables (since BS3). The best way to avoid these kind of overflow issues is not to have dropdowns in tables. You will be able to see the overflow issue on the site if you reduce the table rows to 1 or add more items to make the dropdown really big.

Since removing dropdowns from tables doesn't seem like an option this needs to be handled by whatever dropdown plugin we are using.

[jbalsas]

Yup, this is a known issue for dropdowns, and indeed needs to be handled by the dropdown plugin, which, as @yuchi points out, might be tricky in a metal environment :(

[yuchi]

This is probably a good time to include portals in metal — iff ICD permits.

I’ve been a huge of fan of them in my react projects. See docs →

[jbalsas]

Thanks @yuchi, that's a great suggestion, we'll take a look!

/cc @Robert-Frampton!

[jbalsas]

Support for Portals has been implemented and released in Metal.js@2.16.0. There's a guide about Portals in the site that should be a good starting point to implement this, although I think @Robert-Frampton was already working on it for this...

[yuchi]

Suggestion: have a look at how material-ui@v1 built it with portals.

Short overview:

• they have their own wrapper around React Portals.
• most of the “dropdown” behaviour is driven by the Popover component
• most of the “overlay” behaviour is driven by the Modal components
• it has great a11y features by making the backdrop invisible to screen reader users (aria-hidden="true") and non interactive to all users.