-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling :focus-within
equivalent.
#151
Comments
That is a great question, and yeah, I don't know how you would do this without something like |
Agreed, this is a great question. What is the use case which motivated you to make this change in your fork of the script? |
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 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 :) |
Good use case, thanks! This is annoyingly making me think about modality again, like the original idea @bkardell had... it seems wacky to have Will keep thinking about it. |
We also just ran into this. I have a hidden input inside a label, which I apply focus styles using |
I think |
@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. |
@MarcoZehe is there a demo we could play with? I'm having a hard time understanding the use case. |
@OliverJAsh sorry for the lag. Can you show me what your markup looked like? |
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. |
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 |
@MarcoZehe That makes sense. You're basically replacing hover with focus-visible for folks using assistive tech, but that means that if the hover card contains something focusable you want to keep it from closing when the user tabs to that focusable child inside of the card. Since you mentioned that the user is moving focus inside of the toolbar, could you use focus-within on the toolbar itself to keep it from disappearing? |
@OliverJAsh yeah that's a tricky example... It feels like the issue is really with |
Not quite because then clicking on a toolbar item would mean the toolbar stays open (even after hover is removed), which is undesirable in this case. |
@robdodson Correct! Although consider this example where we don't want to hide the |
Is that because toolbar items are custom components using tabindex? I think a |
they are custom components using tabindex but I don't think the proposed fix would solve my issue without testing |
ah yeah. I believe all browsers retain focus when you click on something with tabindex. Do you want the toolbar to close when someone using a keyboard clicks on the item? Because I think it would still be matching :focus-visible-within at that point. If the button already has focus and you hit spacebar, I don't think it blurs focus. So I think the only way to work around that would be to programmatically move focus out of the toolbar. Which makes me wonder if :focus-visible-within would actually be useful in this scenario? |
I have a scenario where |
Yeah, we've discussed this and a lot of other things like it in csswg. We know we should do something here, it's just not clear what. :has could, in theory solve a lot of things but in practice it is unclear it is implentable. Alternatively, a hundred withins would create their own problems. Sorry I know that's not a real helpful reply. Just wanted to say those are the challenges. |
By "a hundred withins" I assume you are referring to other pseudo-classes. I really don't feel just by adding In addition, I feel that |
+1 for focus-visible-within. If I can give my use-case: This is a |
I agree with @miragecraft — this slope doesn’t seem very slippery? I understand that it seems to cry out for generalization, but the need for :focus-visible-within is pressing in a more we-feel-it-every-day way than other possible functionality that generalized “within” selectors might unlock — and correct me if I’m wrong, but I’d guess that it doesn’t present the same performance challenges as a generalized within selector? This may sound silly, but :focus-visible has been life-changing. We no longer have to dread the we’ll-just-ask-the-new-intern-to-disable-these-focus-rings-if-you’re-gonna-be-so-annoying-about-it workaround. But the matrix is incomplete — without :focus-visible-within, there’s still a subset of cases (which seem pretty random to non-developers) where we have to say “no” to the inaccessibility overlords. In the end, that “no” doesn’t always work even if you stand your ground. To put it another way, the absence of :focus-visible-within, like :focus-visible before it, has consequences on the net accessibility of the web. The reasons for that are embarrassing, but it’s still what often happens. This seems more important than whether the selector is maximally DRY. |
I think there's still some discussion around adding it to In my opinion this may be the best option? |
A good news: folks from Igalia is working on implementing https://bugs.chromium.org/p/chromium/issues/detail?id=669058#c17 |
Does anyone know if any progress have been made here? |
yes!! :has is real, sorta! nobody's shipped it on a main channel yet, but Safari TP has it and Chromium work seems to be ongoing/active (there are related commits from this week it looks like). I'm not how to interpret FF's fourteen(!)-year-old issue though. There are associated issues that look active, but it isn't clear to me whether they're directly related or just "other stuff in selectors 4". |
An additional use case is having a checkbox wrapped by the label where you are styling the label and 'hiding' the checkbox: <label><input type="checkbox" />Label</label> label {
background: blue;
color: #fff;
display: inline-block;
}
input {
appearance: none;
} When tabbing, the focus is set to the checkbox, so if you want to style the label, you need to use focus-within. label:focus-visible, label:focus-within {
outline: 2px solid #21578A;
}
label:focus:not(:focus-visible){
outline: none;
} The above css still shows the outline around the label when tabbing. EDIT sorry, just realized this is the same use case as brought up by @OliverJAsh |
We have a use case for this as well, which I think is a fairly common hack, to show custom focus indicators on checkbox/radio elements using Long-winded way of saying +1, but another I-think-common way of needing it. |
Another use case for :focus-visible-within
When parent container has overflow: hidden and no possibility to change that, :focus-within helps to make indicator visible, otherwise outline of the |
I ran into this today! Had a label wrapped around a radio button / span. The radio button is what I want to detect |
Update re:
|
@bathos I wonder if when |
I wouldn’t think so. To the best of my knowledge those aren’t equivalent. The |
Text nodes are inert, they can’t be focused, even in shadow dom…right? |
@craigkovatch I’m ... not really sure. CSS doesn’t define the conditions for what a UA considers to be a focused node, only a few constraints on how it would need to be defined. The spec explicitly says the set of flat-tree descendents whose status as focused would make their flat-tree ancestor match This could be an artifact of CSS’s generality — it is not specifically an HTML styling language, so it’s agnostic to anything HTML might tell us about what can and cannot be focused here. However even HTML leaves this pretty open-ended. HTML’s notion of focusable areas includes things which aren’t elements, e.g. “scrollable areas”, and again UAs are left free to decide what the exact set of focusable areas are provided certain criteria are met.
I don’t know if there are UAs that consider text nodes to be focused in this sense in practice, but if I understand right they are permitted to. I’d be very curious to learn more about this too — sorry I can’t answer this more properly. (It does seem like it’d be fair to say |
I would have sweared that's what Could you please mention an example where |
@lgenzelis In a tree of DOM nodes, some elements may “host” ShadowRoots. Each ShadowRoot is a little bit like its own document (trying to keep this concise — this explanation isn’t gonna capture any nuance) that can provide forms of encapsulation (including encapsulation of CSS) and functionality typically leveraged by custom elements. If you are not using Briefer: |
Crystal clear, thanks a lot @bathos ! ^_^ |
@bathos if you grep that spec, the "non-element nodes, such as text nodes" is repeated in four different places, so my guess is it's just a generalized statement about certain pseudos, rather than something specifically added about focus behavior. Text nodes can't be focused. Focus is about interactivity, and text nodes aren't interactive. Put another way -- if a text node were interactive, it's no longer a text node. |
From https://bugzilla.mozilla.org/show_bug.cgi?id=418039#c62, at the 8th of January of 2023:
|
The |
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 likebody.focus-visible foo:focus-within
to stylefoo
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.The text was updated successfully, but these errors were encountered: