[DropdownMenu] Possible to specify boundary element for PopperJS collision detection?

[ianduvall]

PopperJS boundary option

Using this screenshot as an example, I'd like to be able to have the DropdownMenu collision detection calculate based off the gray box "Container" element instead of the viewport. In which case I'd expect the DropdownMenu to open up instead of down.

[jjenzz]

We may be able to provide something like this but we do wonder about the UX implications of cases like the following:

In this case, if the Page 1 menu boundary was set to its container, it would drop down (off screen) and wouldn't be accessible without scrolling. How would you expect your example to behave in this case if your menu was at the top of your container?

Perhaps we can have some logic that checks if the container boundary is within the viewport and respects it if it can render without collisions. If not, it falls back to viewport boundaries? 🤔 cc: @benoitgrelard

[benoitgrelard]

Yeah I have similar questions/concerns. Given that these menus are supposed to behave like os-level menus, on top of everything, using as much as the available area to display them is kinda key, by using a custom container, we'd effectively be reducing that "available" area by a lot, especially if there's overall page scroll involved.

[ianduvall]

That's a good point. Thanks for the response.

[jjenzz]

Perhaps we can have some logic that checks if the container boundary is within the viewport and respects it if it can render without collisions. If not, it falls back to viewport boundaries? 🤔 cc: @benoitgrelard

Thoughts on this? It would mean that in the example @ianduvall posted, it would render above until there wasn't enough room and then switch to bottom with viewport as boundary.

[benoitgrelard]

Personally I just don't see the value you gain UX-wise if this is how it behaved. If anything I think it would be more confusing.