Handling `:focus-within` equivalent.

[plinehan]

Is there any plan to handle the equivalent of :focus-within for the :focus-visible pseudo-selector in the CSS spec? Something like :focus-visible-within?

I modified [my version of] the script to add the focus-visible class to the body whenever focus is visible. Then I can write a selector like body.focus-visible foo:focus-within to style foo when focus is visible within it, but I don't see an obvious way to do that in pure CSS once the spec is updated.

[robdodson]

That is a great question, and yeah, I don't know how you would do this without something like :focus-visible-within. I'll add this as a note for @alice and I to discuss when she gets back from vacation. Thanks for filing it!

[alice]

Agreed, this is a great question.

What is the use case which motivated you to make this change in your fork of the script?

[plinehan]

They are almost all cases where we have an input and a set of associated buttons (e.g. a search input box and a "search" button) and we'd like the focus to be around the outer container. I think in most of these we could just use focus-within since the input is always focus visible, but I can imagine cases it would be nice to detect if the search button was visibly focused or not.

We have a few other cases where it just works out conveniently to use focus-within due to how to DOM happens to be constructed. We're retrofitting correct indicators into an extant codebase, so it is handy to have this kind of power :)

[alice]

Good use case, thanks!

This is annoyingly making me think about modality again, like the original idea @bkardell had... it seems wacky to have :focus, :focus-within, :focus-visible and :focus-visible-within.

Will keep thinking about it.

[OliverJAsh]

We also just ran into this. I have a hidden input inside a label, which I apply focus styles using :focus-within. When the label (and thereby input) is actioned via mouse users, we end up showing focus styles. (Unfortunately the team decided to blur the input immediately after use to avoid this.)

[Justineo]

I think :has(:focus)/:has(:focus-visible) are better than :focus-within/:focus-visible-within. Maybe :has is too big a thing to proceed?

[MarcoZehe]

@t3chguy and I are currently beating around something like this in the Riot web client. A toolbar only shows if the mouse hovers over the relevant message. We are at a point where the action toolbar shows up if screen readers or keyboard users move into the actual message tile, but the way CSS is set up right now, with the .focus-visible polyfill, the toolbar disappears once the screen reader moves focus to a button inside the toolbar. Even though that is within the toolbar and on an actionable button. So having this would be really awesome, since we can't seem to convince the powers that be to always show the toolbar for each message in the chat.

[robdodson]

@MarcoZehe is there a demo we could play with? I'm having a hard time understanding the use case.

[robdodson]

@OliverJAsh sorry for the lag. Can you show me what your markup looked like?

[MarcoZehe]

The use case is Riot Chat that shows an action bar for each message when hovering over it. However, there are a few situations where this doesn't work reliably, for example for screen readers, we adjusted this to also be :focus-within, but that doesn't fire in all situations. We need to do this so screen reader and keyboard users (once full keyboard access is implemented) have access to all controls no matter where within each message container the focus happens to be.

[OliverJAsh]

@robdodson https://jsbin.com/fokexoc/1/edit?html,css,output

[robdodson]

hm yeah both of these make sense. It looks like the TAG folks added a CSS selectors level 5 label to the prior discussion here: w3c/csswg-drafts#3080 (comment)

I wonder if they're thinking of exploring the :focus() or :has() option...