<s-popover> improvements

does that include having it be scrollable? otherwise I have a full working implementation, but as shown above its not usable since it doesn’t behave correctly when there are too many options.

Here’s a hacky solution I found to open/close the popover programatically while the Shopify dev team implements an official way to do this:

       <s-search-field label="Search" labelAccessibilityVisibility="exclusive" placeholder="Search products" onInput={(e)=>{
const commandEvent = new Event("command");
commandEvent.command = "--show";
commandEvent.source = e.target.shadowRoot.firstChild;
commandEvent.F = commandEvent.source;
popover.current.dispatchEvent(commandEvent);
        }} onBlur={(e)=>{
const commandEvent = new Event("command");
commandEvent.command = "--hide";
commandEvent.source = e.target.shadowRoot.firstChild;
commandEvent.F = commandEvent.source;
popover.current.dispatchEvent(commandEvent);
        }} />

<s-popover ref={popover} id="product-search-popover" placement="bottom-start">
            Popover!
</s-popover>

While a programatic solution would be welcome, an alternative would be to just allow commandFor and command on the text inputs and handle that automatically just the way it does with buttons.

Note: The .source / .F property is the element relative to which we want the popover to be positioned. Also, without the blur event, the show command only works once.

@Anthony_Frehner why not support the Popover API? Seems like a widely supported, standards-compliant way of adding programmability.

Popover API is only usable with the anchor API, which is only available from Safari 26, and not yet on Firefox (popover API are forced to be on the top-layer, so you cannot positioned them absolutely; so any kind of non-trivial positioning requires the anchor API).

It seems a bit too early to base something critical like Shopify admin on this API. Usage of Safari 15 is still quite high. As much as I love this API, I don’t think the popover API will be usable for anything critical before at least 3-4 years (Apple unfortunately locked many devices on Safari 15 so we’re kinda stuck here).

I have spent a bit of time "hacking” the popover to work with a text input to have an autocomplete component. I can get it 95% polished but it is missing a lot of accessibility features like aria-activedescendant and aria-controls correctly linked to the popover.

<s-clickable
  id="simple-activator"
  commandFor="simple-popover"
  command="--show"
>
  <div style={{ backgroundColor: "white" }}>
    <s-search-field id="simple-search" label="Search" />
  </div>
</s-clickable>

<s-popover id="simple-popover" inlineSize="auto">
  <s-box padding="base">
    <s-text>Popover content here</s-text>
  </s-box>
</s-popover>

I have a more complex example where I can add in functionality to set the popover minInlineSize to match the simple-activator, introduce keyboard functionality to select items in the popover, and additional clickable areas for checkboxes in the popover. The issue is that the aria controls are on the shadow button of the clickable element instead of the association with the input.

Outside of the accessibility issues the popover is missing the ability to be aware of it’s own height. If the popover appears above and you start to auto-complete the height will shrink creating a big gap between the popover and commandFor element.

Additionally there is some bugginess where focusing into the input the 1st time will trigger the trigger the popover, but clicking again on the already focused input will close/hide the popover without triggering any of the popover events.

Codepen example with the simple and complex example: https://codepen.io/moore/pen/XJdWVWN