- From: Westbrook Johnson via GitHub <noreply@w3.org>
- Date: Fri, 03 Apr 2026 19:46:24 +0000
- To: public-css-archive@w3.org
> You don't want to show focus outlines on all shadow hosts ancestors of an input, that's why it wasn't done.
Interesting. And, makes sense. However, the trouble is you can use CSS to make that not happen, but there's nothing (reliable) that you can use to make `:focus-visible` propagate up. 🤔
It's almost like we need a `:focusable` pseudo selector to tie `:focus-visible` to in the user agent stylesheet that adds that outline rather than just `:focus-visible`.
```
:focusable === input:not([inert]),
select:not([inert]),
textarea:not([inert]),
a[href]:not([inert]),
button:not([inert]),
label:not([inert]),
[tabindex]:not([inert]),
audio[controls]:not([inert]),
video[controls]:not([inert]),
[contenteditable]:not([contenteditable="false"]):not([inert]),
details>summary:first-of-type:not([inert]),
details:not([inert]) {}
```
Then when `<custom-element>` matched `:focus-visible` it wouldn't get a loop by default, unless it also has `[tabindex]` and not `[inert]` unlocking the ability to use `:has(:focus-visible)` in that same tree or above.
🥹
--
GitHub Notification of comment by Westbrook
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3080#issuecomment-4184944772 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 April 2026 19:46:25 UTC