Follow-up question: the same lack of visible transparency/blur now also shows up on another element that shares the .menu-panel styling path — the header search dropdown’s input field (.search-input-wrapper, part of the glimmer search menu).
Recipe (identical pattern to the working .d-header one, and to .menu-panel above):
.search-menu .search-input-wrapper {
background: color-mix(in srgb, var(--header_background) 85%, transparent) !important;
-webkit-backdrop-filter: blur(6px) saturate(1.2);
backdrop-filter: blur(6px) saturate(1.2);
border-radius: 14px;
box-shadow: 0 0 0 1px var(--primary-low-mid);
overflow: hidden;
}
.search-menu .search-input {
background: transparent !important;
}
What renders correctly: the hairline border (box-shadow) and the border-radius both show up exactly as expected — so the selector is matching the right element and the rule is applying, not getting silently overridden.
What doesn’t render: no visible translucency and no visible blur of whatever’s behind the field, same symptom as .menu-panel (sidebar/hamburger panel) reported above. .d-header, using the literal same three lines (background-color via color-mix, -webkit-backdrop-filter, backdrop-filter), continues to work fine.
This makes me increasingly suspect it’s not specific to .menu-panel itself, but to something these dropdown/overlay-style elements share (stacking context created elsewhere in core, a compositing layer that isn’t a proper containing block for backdrop-filter, or similar) — rather than anything about our own selector or property values, since the exact same three CSS properties behave differently depending on which core element they’re attached to.
Has anyone run into backdrop-filter/translucent-background not rendering specifically on the search dropdown or other .menu-panel-family overlays, even though the same recipe works on the header?