listbox of sl-select renders behind other elements with container-type set on parent

[kirchsuSICKAG]

Describe the bug

Having a sl-select in a parent element with container-type set to something different then normal leads to the listbox of the select no longer rendering over other elements (which are not part of the container-type parent).

This seems to be a problem with the sl-popup. Because this behavior can also be achieved with the popup ( which is also used in the select)

To Reproduce

• See following code pen for an example with the sl-select: https://codepen.io/kirchsuSICKAG/pen/rNEgZKW
• See following code pen for an example with the sl-popup: https://codepen.io/kirchsuSICKAG/pen/gONJddZ

Screenshots

Browser / OS

• OS: Mac
• Browser: all
• Browser version: -

Additional information

I'm not sure, if this is even fixable in the component itself, or if it is something, which the user of the sl-select has to be taken care of.
The container-type is creating a new stacking context. If adding position: relative and z-index:1 (or some higher z-index, that the other elements outside of the container-type element has), the rendering is done correctly again.

[claviska]

Please try using the hoist attribute as a workaround. Soon we’ll be moving to the Popover API which will use top layer.

[KonnorRogers]

So the problem you're hitting is the CSS containers create a new "stacking context", as such, its causing the issue you're seeing.

The "fix" seems to be adding position: relative; z-index: 1; to your .container like so:

https://codepen.io/paramagicdev/pen/RwzmOYY

Here's like a minimal reproduction of how container-type makes a new "stacking context", our form controls do have position: relative;and so they roughly mirror the issue you see in the codepen below:

https://codepen.io/paramagicdev/pen/QWXRPRb

[kirchsuSICKAG]

Thanks for the answers.
Unfortunately the hoist attribute does not work, but we will use the position:relative; z-index:1 variant 👍