Replies: 3 comments 4 replies
-
Hi @rafgraph, thanks for bringing this up. Yeah, this is a tricky one. With our primitives, we try to stay as style-agnostic as possible. We don't really want to have opinions on that front, as much as possible. Most of the things mentioned here "mostly" about styling. I say "mostly" because the line between styling and intrinsic functionality can sometimes be blurry. This is definitely something we need to explore more though. We've discussed this a little with the team, and we generally don't think "responsive" primitives is the way to go. We think we'd rather expose some more specific "mobile" parts which people can swap at will. So for example, we may decide to expose a Another temporary solution might be that we unlock our primitives even more in some areas. We try to keep them as open as possible by exposing all the parts but there are still some bits that aren't exposed. For examples positioning wrappers/portals, etc. If we were to expose those, you would be able to override them to suit your needs better. This is all just ideas in our heads at the moment, as we have had other priorities to pursue for now but this is most definitely something we would like to solve at some point. |
Beta Was this translation helpful? Give feedback.
-
Hi there! I was wondering if there's been any progress on the proposed ideas that @benoitgrelard had mentioned previously? Or if not, @rafgraph - were you able to turn your dropdown menus to be mobile-friendly? I am struggling to figure out how to get the |
Beta Was this translation helpful? Give feedback.
-
Hi there, I stumbled upon the same problem, so I would like to share my solution, and ask if there are any progress about. Regarding the main Content height, I used the ScrollArea component to add and set a max height (thanks to <DropdownMenu.Content>
<ScrollArea.Root>
{children}
</ScrollArea.Root>
</DropdownMenu.Content> Then for sub content, I just hide it when in mobile and then show another Dropdown.Group which then is hidden on desktop. So I made some new prop to show/hide menu items and groups of items depending on breakpoints. But I like the idea of I have some issue with sub content, when it's being open and I scroll up/down, then it doesn't close sub content, but I didn't yet check into how to close programmatically maybe when scroll happen (like for example stop scroll area when sub menu is open by setting overflow hidden?), see: |
Beta Was this translation helpful? Give feedback.
-
Hi, I really like the potential of the DropdownMenu component, but it easily runs out of screen real estate on small screens. This happens with sub-menus, long menus, and when using a mobile device in landscape mode, etc (also adding
overflow-y: scroll
toDropdownMenu.Content
doesn't make make the menu content scrollable).In general I don't think the overlay pattern is well suited for mobile devices because of these issues (unless the content is only a few items).
On small screens is it possible to show the menu not as an overlay? That is, either expand the page down to show the menu items, or have it take over the whole screen when it's opened? Also, the sub menu would need to expand down, instead of to the side.
If it's not currently possible, it'd be nice if you'd create a responsive version of the DropdownMenu. To take this a step further, it'd be awesome if you separated the menu content from the menu trigger type. With the trigger type being dropdown, context, expand page, whole screen, something custom, etc, so that the same menu content can be shown in different ways depending on the screen size and positioning on the page (i.e. responsive).
Beta Was this translation helpful? Give feedback.
All reactions