Here I am thinking about `:focus-visible-within`...as one does. And wondering, if #CSSWG doesn't think there's a valid path forward on their end, would it make sense to add a `focusVisible` property to `FocusEvent` (or more specifically the `focusin` event, is scoping were beneficial): https://github.com/w3c/csswg-drafts/issues/3080#issuecomment-3999919565 šŸ¤”

What do you think? Maybe I'm the crazy one... 🤣

#webdev #js #developingDesignSystems

Do we need :focus-visible-within ? Ā· Issue #3080 Ā· w3c/csswg-drafts

While looking to close out w3ctag/design-reviews#233, one other thought occurred to me: Is there a need for :focus-visible-within to complement :focus, :focus-within, and :focus-visible? In particu...

GitHub
@westbrook Unless I’m misunderstanding what you’re trying to do, isn’t this possible with `e.currentTarget.matches(":scope:has(:focus-visible)")` https://codepen.io/noleli/pen/EagPBew
:has(:focus-visible) in event handler

...

@noleli Yes, _and_ I also want support for https://codepen.io/Westbrook/pen/wBzMVKM. Hence the use for `focusin`, as least in light of difficulties on the CSS side.

🄲

:has(:focus-visible) in event handler

...

@westbrook Ah interesting, so the problem is that :has() doesn’t traverse shadow boundaries? Is it totally off base to think that it could be framed as a focus delegation issue? Like, if a shadow root delegates focus and the thing inside is focused I want the host to consider itself to have focus (within) from the perspective of the light dom.

@noleli I'd much rather it be more complex than that...

`div:focus-within` "pierces" through all depths of the DOM but is agnostic to the accessible context with which the user is interacting with the page. I'm looking for it's soul mate in visible focus.

@westbrook hmm, that does make sense. I like the language, too: `within` is somehow more evocative of something inside, no matter how. `has` is more ā€œI have this in the tree that I have visibility into.ā€
@westbrook random thought (delayed from the original thread). Instead of :focus-visible-within, would it make sense to have a shadow-piercing pseudo `:has-within()` that can take any state pseudoclass (e.g., :disabled) or custom :state()? It just occurred to me and I haven’t thought too deeply yet about whether it would feel too leaky/break encapsulation too much, but my initial thought is that limiting it to state makes it acceptable. (possibly related discussion https://github.com/w3c/csswg-drafts/issues/3072)

@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

@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

@westbrook

> 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.
Yes, šŸ’Æ. Your screenshot perfectly illustrates the inconsistency there.

And state being reported up doesn’t feel leaky because state is part of an element’s public API, not an implementation detail. It’d be a breaking change for :has(), though, which might necessitate a new selector anyway.

@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. 🤣

@westbrook Haha, that’s fair, depends on frame of reference. If the behavior of :has(:focus-visible) changes, is it that :has() can ā€œseeā€ more through shadow boundaries than before (a change for :has()), or that :focus-visible, as a state pseudo, is reported up (a change for :focus-visible).

Either way, if someone is relying on the current behavior for something (though I have no idea what that would be because the current behavior is ā€œit doesn’t workā€) it seems potentially risky/breaking.

@westbrook In practice, though, I think you’re right, it’d be a low-risk, high-reward change