[bug][sl-select] Options container Ignores z-index, overlaps sticky header.

[kssc4567]

Describe the bug On a page with scrollable content and a sticky header, the sl-select button scrolls under the header but the options scroll above the container, overlapping it. Header (yellow) has z-index: 9999 and position one of: static, sticky Options div listbox popover (red) has position: fixed (in addition with enforced z-index: 1)

To Reproduce Steps to reproduce the behavior:

1. A page with a sticky header and scrolling content and sl-select
2. Click the sl-select to show options
3. Scroll down so sl-select and its options are cropped by the window
4. See error

Actual behavior sl-select button is behind the header sl-select-option popover is in front of the header

Expected behavior sl-select button is behind the header sl-select-option popover is behind the header

Screenshots

Desktop (please complete the following information):

• OS: iOS
• Browser Chrome
• Version 123

Additional context

• Angular 15

### Tasks
- [ ] hide panel on scroll

[jpzwarte]

@kssc4567 a [popover] element is by default displayed in the "top layer". This is a new layer in the browser where modal dialogs, popovers etc. are shown. This top-layer is by default above any other element not in the top-layer (no matter the z-index). See https://developer.chrome.com/blog/what-is-the-top-layer

[kssc4567]

Thank you for your kind reply but in case of a header the problem is more complicated. We have 2 additional factors here:

1. That's a fixed header. Would you advise it being in a popover as well? We'll then have another issue because the last item in popover is on top, anyways. Therefore opening select options will put them on top.
2. Popover for sl-select-option's got a delay when scrolling (at least in the current implementation, maybe due to the polyfills we have to use for the CFA).

Maybe there should be a SLDS component for the header in such case? With optional scrolling (fixed)?

[Diaan]

There is quite some discussion about what the correct behaviour is. Researching this I came across 3 options:

1. Keep as is (popover is always on top of everything else)
2. block scrolling when popover is open
3. close popover on scrolling.

Options 2 and 3 are both used in the native HTML-select component. Option 2. in all browsers on MacOS and Firefox on Windows, option 3 in other browsers on Windows. Options 2 and 3 will also impact the fact that a popover placed in position where it can possibly move around because of scrolling can never be higher than 50% of the viewport; When the trigger (the select in this case) is in the center of the screen the popover can not go past the edge of the screen, because you can't scroll to see the last option.

From a usability viewpoint option 1 sounds like the best option. So the question is, how important is the fact that the dropdown on top of the header might look a little bit funny.

[Diaan]

We found a 4th option :D Something that is proposed in the W3C specs; keep the popover open until the trigger is no longer visible: https://drafts.csswg.org/css-anchor-position-1/#position-visibility

I'll try and implement this solution.

[Diaan]

There will eventually be a native solution using position-visibility: anchors-visible, but that doesn’t work cross-browser yet and also doesn’t work in the polyfill we use right now. I tried to emulate the behaviour, by hiding the popover when the component that triggered it (the anchor) scrolls out of view, as determined by the intersection observer. The only downside is that is doesn’t register when it is behind something that is sticky. so there will be a couple of pixels during the scroll where you still see the popover on top of the header, but if you scroll further it hides. You can see my solution here: https://kind-plant-088739303-1324.westeurope.1.azurestaticapps.net/?path=/story/form-select--hide-when-out-of-view I’m interested you hear what you think about this solution.