Consider `portal={false}` default behavior for components with popovers
See original GitHub issue⭐ Enhancement
Current Behavior
All of our components with popovers currently default to opening in a portal. There are pros and cons to this approach.
AFAICT, the biggest pro is that you don’t need to worry about inheritance or potential positioning weirdness with nearby elements. As far as cons:
- In some applications, tab order is still relevant and breaks when trying to move from a control into the popover. See https://github.com/reach/reach-ui/issues/284.
- If a user scrolls when a portal’d popover is open, the browser has to catch up and update its position on the fly. This creates a janky experience across the board.
- Some custom styling is much simpler when rendering the popover inline. See https://reacttraining.com/reach-ui/combobox#custom-styling
Desired Behavior + Suggested Solution
Consider making portal={false}
default in affected components. (MenuButton
, Combobox
, Listbox
)
Who does this impact? Who is this for?
All users, but the most significant impact is likely screen reader users.
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Components / Popover - Default ⋅ Storybook - NET
A popover displays content on top of other content. Best practices. Do. Use the trapFocus prop when focusable elements are in the Popover...
Read more >Popover Usage - ServiceNow Developers
Learn how popover behaves when the display changes or a user interacts with the component. Responsive behaviors. Like modal behavior and dropdown action...
Read more >Popover - Shopify Polaris
Popovers are small overlays that open on demand. They let merchants access additional content and actions without cluttering the page.
Read more >Popover - Carbon Design System
A popover is a layer that appears above all other content on the page. Only one popover can appear at a time and...
Read more >Popover | Workbench by Gusto
Guidance on implementing the Workbench Popover component. ... persistent, boolean, false, By default Popovers behave like pseudo-pages in the application ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
No problems! There’s also this video I recorded for Automattic which talks exactly about that: https://www.youtube.com/watch?v=tUlB13vUcac
I mean, the focus trap would be used, in this case, to “transfer” focus to the correct element, and not to retain focus within the popover.
I’ve made some experiments here: https://codesandbox.io/s/reakit-portal-popover-tab-sequence-d4vb3
But it still doesn’t work on iOS/VoiceOver as the swipe gesture doesn’t really move DOM focus, so the
onFocus
handler on the traps is never called.