@zacky A great question, and certainly a reason to hope that Chrome wouldn't have much issue getting into this style of selector!

However, these's no _self_ selector in `:host-context()`. Always it's interpreted as:

```css
:host {
.host-context & {
/* You're in a host context. */
}
}
```

It being deprecated, maybe the same intrepid implementor who was going to pull this out of Chromium would be interested in replacing it with extended `:host:has(...)` and `:host(:has(...))` support 🤞

@bramus I'd argue the the use of `--arg` makes the application of the value local, which aligns more to this: https://codepen.io/Westbrook/pen/raMJByv than to what you've shared.

Maybe that's not _how_ mixins work, but it's definitely how I'd read them. Your example feels more like the mixin is:

```css
:root {
--foo: 10em;
}

@mixin --foo() {
@Result {
&, & > h2, & + p {
width: var(--foo);
}
}
}
```

@noleli What!?! 😲 How do you see it being a breaking change for `:has()`?

Naively, if we could normalize reporting of `:focus-visible` to be like `:focus` then we'd be able to get `:has(:focus-visible)` to work just like `:has(:focus)` works today, right?

I could see someone saying that's a breaking change to `:focus-visible`, but I'd argue it was "fixing" it, but that's certainly in the eye of the beholder. 🤣

@noleli Makes me think more on the state here. Maybe it's not that we should have a more introspective selector here. Maybe it's that we're not adequately reporting up the state. If a shadow host can be `:focus` when a child is focused, then why can't it be `:focus-visible`? With such a thing then `:has(:focus-visible)` would work in this case.

Not sure the right solutions, but something SHOULD be done here! 🤞

#webDev #CSSWG #a11y

2/2

@noleli That's interesting!

The sort of default response is that something intended to traverse the shadow boundaries is possibly content leaking. Which might also apply to the `:focus-visible-within` construct 🙈

1/x