Context

• Related to @wordpress/components: portal behavior of popover-based components #63697

As we're re-writing some of the components in the @wordpress/components package to use ariakit, we have the chance to re-discuss our approach to architecting our APIs and the behavior of such components.

More specifically, as we're working on the new version of DropdownMenu and CustomSelectControl, one of the aspects that we should discuss and agree on at a package level is the modality of popover-based components.

Using ariakit allows us to easily switch the modality (and related behaviour) of popover-based components (popover, tooltips, dropdowns, dropdown menus, dialogs, selects, comboboxes...) via a few props.

In ariakit there are some related aspects that come with modality (and can be customized to a degree):

• by default, modal popovers are portal'ed and appended to the document.body, while non-modal popovers are rendered inline
• by default, modal popovers prevent scrolling on document.body
• in modal dialogs, the level of ariakit-provided headings is re-set so that they start at h1
• a hidden "dismiss" button is rendered in modal popovers

What

Therefore, we need to decide:

• What should the default modality of popover-based components be? Should it be different depending on the component?
• Should we expose APIs in our components to change such modality? If yes, for what components and in what shape?
• Should make amends to the default ariakit behavior re. inline vs portaled popover depending on the modality?
• Should make amends to the default ariakit behavior re.preventing body scroll depending on the modality?
• Are we ok with the addition of a hidden dismiss button for modal popovers?
• Do we need to take any additional precautions into account, given that there will be a transional phase during which some components will use the ariakit popover, and other components will use the first-party Popover from this package?

cc @WordPress/gutenberg-components