Background

The Popover component has a prop, useBottomSheet, that when true, outputs the popover as a bottom sheet until the viewport is 640px or wider (i.e. above the mobile max-width). At that width, the component is displayed as a popover anchored to another element on the page.

In two products currently under development, we've identified use cases for a popover that displays as a bottom sheet regardless of viewport size. For example, the popover that will display when a user presses the bookmark button on an article as part of the Custom Lists project should always be a bottom sheet in the MinervaNeue skin and should be responsive (the current behavior of Popover) in the Vector 2022 skin. Similarly, the post-publish account creation CTA for temp account edits was a mobile-only experiment and the team found that the popover simply does not display over the mobile breakpoint if no anchor point is provided.

We want to enable use of the bottom sheet on all viewport sizes.

Design requirements

Design artifacts to be added

Open questions

1. What is the max width before the bottom sheet is no longer the full width of the viewport?
2. Can we/should we make that configurable?
3. What should the border radius of the bottom sheet be when it is not the full width of the viewport?

Requirements

Technical requirements

1. Figure out a sensible way to add configuration to turn on the bottom sheet all the time, that doesn't disrupt the existing use of use-bottom-sheet="true". In an ideal world we might change that prop to take strings like "responsive" and "always". We could change the prop to accept both boolean values and these strings. Then for a future major Codex release, we could deprecate then remove the boolean usage.
2. Implement and document the "always" behavior according to the design spec

Acceptance criteria

• Popover supports displaying as a bottom sheet regardless of viewport size
• Current responsive behavior is still functional and the default when useBottomSheet is true
• Existing implementations using useBottomSheet are unchanged (note - it actually looks like this is only being used by the Growth team so far)

QA strategy

• Risky change? Risk of regressions for existing usages, which are very limited. Not controversial.
• QA by: QA engineers, engineers, designers, and/or PMs from involved teams
• QA in: Codex docs site first, locally for new products using the feature, beta or prod for existing products using useBottomSheet
• Test steps: to be added

Communication criteria

n/a

Rollback plan

Revert the Codex release patch in core if possible, hotfix Codex and perform another release otherwise

This task was created by Version 1.1.0 of the Reader Experience team task template using phabulous.