Menu dropdown panel renders incorrectly with filter on Chrome

[threeseed]

When you use a menu within a div that is applying a filter on hover it renders incorrectly.
It is only an issue with Chrome and only an issue when using a filter.

To Reproduce
Steps to reproduce the behavior:

1. Visit https://jsfiddle.net/18b6Lvfx/1/
2. Click on the button to open the menu panel.
3. Hover your mouse over the background-image and notice how the menu panel also moves.

Expected behavior
If you try with Safari you see the expected behaviour i.e. menu panel doesn't move.

Desktop (please complete the following information):

• OSX: 10.15.7 (19H2)
• Browser: Chrome
• Version: 78.0.3904.87 (Official Build) (64-bit)

[claviska]

While this behavior isn't straight-forward, it's not a bug. It's a side effect of using a fixed positioning strategy via hoist and how fixed positioning works in HTML/CSS. From the docs:

Dropdown panels will be clipped if they're inside a container that has overflow: auto|hidden. The hoist attribute forces the panel to use a fixed positioning strategy, allowing it to break out of the container. In this case, the panel will be positioned relative to its containing block, which is usually the viewport unless an ancestor uses a transform, perspective, or filter. Refer to this page for more details.

In your case, removing the hoist prop will resolve it (unless your use case requires overflow: hidden).

The reason two positioning strategies are offered is because everything is contained in the <sl-dropdown> component and, depending on how it's used, you may need to break a dropdown panel out of an overflow: hidden container from time to time.

Because dropdowns use a shadow root and everything is contained in it, traditional hoisting can't be done (e.g. moving the panel to just before </body> when it's activated). This is because styles are encapsulated so those plus slots stop working when you move things outside of the shadow root.

What we really need is something like position: popover:

Before landing on the current API, I experimented heavily with different hoisting options, including moving things around in the DOM, cloning the panel, creating a separate component for the panel — none of them were clean solutions, nor did they provide an intuitive API for users.

That said, I'm closing this since the behavior is documented and expected. The only way I can think to address this sanely in the future will be with a new CSS property.

[claviska]

I finally took the time to start this discussion with the CSS WG. If you're interested, you can follow along here: w3c/csswg-drafts#5699