feat(topbar): add popover child component

[dancormier]

STACKS-613

This PR adds a Stacks topbar popover component so we can control the size and overflow behavior, primarily to meet the success criteria for WCAG SC 1.4.0 Reflow.

[!NOTE] I still need to add tests to this PR, but I'm opening it for review to get eyes on it earlier rather than later.

New classes

This PR introduces the following child component classes to the topbar:

• s-topbar--searchbar--popover: This class applies a few sensible defaults to the popover in this context (specifically it sets padding to 0 and min/max width)
• .s-topbar--searchbar--popover-content: This class is intended to wrap the content within the popover to ensure it can resize and scroll vertically (if necessary)

Concessions

Since the topbar height is set with --theme-topbar-height, we know the height of the topbar for certain, but we cannot know for sure what the height of the search group is when it's rendered below the topbar (in the case of small viewports). Because of this, I took an educated guess and yielded on the side of caution to ensure the popover is rendered within the viewport.

It would be unlikely consumers would manually alter the height of the search group in mobile in such a way that it's significantly larger than the default, potentially rendering a portion of the popover outside of the viewport boundaries. I think this is a safe approach but I'm willing to reconsider if objections arise.

TODO

• [ ] Add tests specifically for the popover when it's shown
• [ ] Before merging: Remove excess popover content

Screenshots

320 x 256


770 x 256


To test

For ease of testing this PR, I've added the popover to the main topbar of the Stacks docs site. It's temporary and will be removed before merging this PR.

• Go to the Stacks docs
• Focus the search input in the main topbar of the docs site
• Notice the addition of a popover anchored to the search input
• Make the browser real small and notice the popover resizes to stay within the boundries of the viewport and introduces vertical scrolling if needed.
  • Tip: 320 x 256 is the min supported viewport size

Bonus if you're ambitious (I don't necessarily recommend it, though)

• In the topbar docs page, test out some of the other topbars and their respective popovers
  • You'll notice some overlapping issues. Ignore that since it's a docs-only issue.
  • You'll also notice you need to scroll so the topbar you're interacting with is where a topbar would be on the page (at the top, usually 😝) in order to see the expected behavior wrt height. This is why I included the popover in the main topbar. You're probably better off just testing it there.

[netlify[bot]]

✅ Deploy Preview for stacks ready!

Name	Link
🔨 Latest commit	794a841b80a3548fa5a206d9ef1e2a786c466449
🔍 Latest deploy log	https://app.netlify.com/sites/stacks/deploys/6658cd27f211ff0008598e90
😎 Deploy Preview	https://deploy-preview-1739--stacks.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[dancormier]

@CGuindon

For the overlapping issue that should be Stacks only, would this same issue appear on Teams? They also have both the helper and results — would those two popovers now overlap?

On Teams, there's just a single popover that gets its contents swapped out when results render. It shouldn't be an issue there.

Also, I don't know how to test this with the overlapping of two popovers? I can't see the results on small screens.

I should've specified that the Algolia search suggestions popover is not a native Stacks popover so exclude that from your testing. I added a dummy popover to the search for demonstration purposes and plan to remove it once this PR is approved, and that's the one I recommend testing against (you can get only that popover to show by only focusing the search input)