[popups] Allow `Positioner` parts to be omitted

[atomiks]

Closes #1663

CSS anchor positioning preview: https://deploy-preview-1668--base-ui.netlify.app/experiments/css-anchor-positioning

Limitations:

• You can't use Arrow parts without Positioner
• --transform-origin doesn't work
• Positioning acts differently (no shifting)
• Doesn't apply to Select since it requires JavaScript

[netlify[bot]]

✅ Deploy Preview for base-ui ready!

Name	Link
🔨 Latest commit	bb80995fd086c906f4b8529131a5c1b6ac98f9b0
🔍 Latest deploy log	https://app.netlify.com/sites/base-ui/deploys/67ee479f6f98260008a8a7b9
😎 Deploy Preview	https://deploy-preview-1668--base-ui.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.

[atomiks]

CSS anchoring demo isn't final but this solves the issue of Positioner parts not being allowed to be omitted

[benface]

Could the Portal part also be made optional, to render menus inline?

[michaldudak]

@benface The Portal part also handles mounting and unmounting popups. We made it that way, as usually it's desired to render popups outside of the rest of the application's DOM branch.

If you need to render something in place, you can create a container where you want the popup to appear and reference this element in the Portal's container prop. I realize it's not the most convenient way, but these cases should be rare. If we see more devs complaining about this, we can reconsider the API.

[benface]

@michaldudak – Thanks for the answer. I am using the container solution and it's working well, except for two things:

1. When there's a nested menu and I want that one to be "positioned" instead of rendered in place / in the same container as the parent menu, the focus doesn't properly return to the trigger when clicking on a submenu item. I made an issue about this in #1809, but based on @atomiks's answer, it sounds like it's intentionally not supported.

2. I'm guessing this is even less supported, but it's not 100% clear from the docs and I'm not getting any exception when I try it: if my "inline menu" doesn't even have a Menu.Trigger and I just want it to be open all the time, or open based on some conditions different than activating a button, focus management seems broken: I'm not able to enter the menu with the Tab key. Maybe Menu.Trigger is meant to be required?

[michaldudak]

@benface, technically, the Trigger part is not required, as you can control the menu's open state from the outside (as in https://codesandbox.io/p/sandbox/agitated-kare-94567v?file=%2Fsrc%2FApp.tsx%3A16%2C22), but I assume this will be a quite rare scenario.

Having an always open menu is not quite supported indeed, though. We even tried using it this way internally to implement a menubar, but it didn't work well. An always-open inline menu is more of a listbox, though (which we're also considering implementing).