- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Feb 2021 17:23:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[selectors] :focus-visible and Shadow DOM`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [selectors] :focus-visible and Shadow DOM<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5893<br> <dael> rego: Both are about focus-visiable. This is about what happens when you have shadow dom<br> <dael> rego: focus pseudo element matches when you have focus in a shadow tree so matches in shadow-host. Wondering if focus-visible should match.<br> <dael> rego: Special thing is WK has -wk-direct-focus pseudo call<br> <dael> rego: People use it in UA stylesheet to avoid outline when you focus in the shadow tree.<br> <Rossen_> q?<br> <dael> rego: In chromium in this case if you focus the input in the shadow tree you get the focus indicator. I believe focus-visual is about avoiding people removing the outline with focus outline:none<br> <dael> rego: Tricky part is in theory you shouldn't be able to know if an element is shadow host. Thanks to that you could check if it is a shadow host. There are other cases wher eyou can do that. shadow host only matches in some cases. Need to think about it<br> <dael> rego: with WK solution you can inspect if it's in shadow host because you can focus it and check if there's an outline shown.<br> <dael> rego: It's a trick.<br> <dael> florian: QUestion on indirect level. Asking if we should show focus-visible in this case, but focus-visible isn't defined when it shows. Ther'es heuristics, but it says it should match when focus indicator is shown. Are you trying to spec more detail on when browser shows?<br> <dael> rego: It would be adding one more item on the heuristic list to allow this case. One could be browsers don't show focus indicator in shadow host when there's an element in shadow tree with focus. It would be add a heuristic since current impl follow the heuristic. It's non-normative, but adding one more heurisitc<br> <Rossen_> q?<br> <dael> Rossen_: Back to shadow root topic. I was re-reading thread in issue. Appears topic is discussed but not solved.<br> <dael> Rossen_: If I hear you, you're saying there are other precedents which would allow shadow root detection. If this is a fact we shouldn't necessarily add things to make it easier and more obvious to detect<br> <dael> Rossen_: Where is the current thinking on that?<br> <dael> rego: When you focus an element you're not sure if it will match focus-visible. When you focus inside shadow tree if shadow host doesn't match maybe you have it for a reason because user did a different way to focus.<br> <emilio> q+<br> <dael> rego: There's another open issue on how that makes shadow host observable<br> <dael> Rossen_: Right. I think Alex's last comment summarizes it well. [reads]<br> <rego> s/Alex/Alice/<br> <Rossen_> q?<br> <dael> Rossen_: This doesn't seem to have the answer. I see your comemnt pointed to another issue. Seems up in the air<br> <dael> rego: I agree with Alice. I think Alice would be fine not matching focus-visible in shadow root. emilio might have something to say<br> <dael> emilio: I agree with Alice but for a different reason. Don't agree we're only probablistically exposing. Given spec heuristics you can force focus-visible to show. If we want focus-visible to be used it needs to not match shadow host or not match from UA rules. Don't know if we have precidence for UA rules<br> <rego> Chromium also implements the :focus propagation on delegateFocus:true, that's why you get 2 outlines in Chromium<br> <fantasai> https://drafts.csswg.org/selectors/#the-focus-visible-pseudo needs fixing to use RFC2119 terminology correctly :/<br> <Rossen_> ack emilio<br> <dael> emilio: WK is only one that impl and they have special pseudo class for UA stylesheet. I think either column-focus or focus-visible should do the right thing or they shouldn't match. Right is if you use from UA stylesheet it shouldn't show on shadow host ancestors<br> <dael> Rossen_: Catching up on IRC chat.<br> <dael> Rossen_: emilio, the overall take away is you agree with problem of exposing awareness of shadow host, though for a slightly dirrent reason?<br> <dael> emilio: Yeah. think it's solvable if we have special case to not prop. I don't know if we want to go that root<br> <dael> s/root/route<br> <dael> emilio: And we would still expose via gCS so I don't feel too strong. Either do what rego and Alice propose or making focus-visible do right thing from UA stylesheet are workable<br> <dael> Rossen_: What is the ask here, rego?<br> <dael> Rossen_: Asking for resolution with the proposed behavior you summerized in opening comment?<br> <dael> rego: One option could be resolve we don't want focus-visible to match shadow host. Maybe we should explore alternative from emilio in the issue<br> <dael> Rossen_: For me that would be preferred path. I don't feel like conversation with Alice is resolved. emilio you can expand your proposal further<br> <dael> emilio: Can do<br> <dael> fantasai: My understanding is definition of this pseudo class is it will match when UA is doing something to style a focusable element as focused and will not match otherwise. If UI default focus was a dotted outline around everything if the author replicated that they should get same behavior as UA would give. All heuristics after example are suggestions of things UA should think about when they match focus-visible in general<br> <dael> fantasai: Meaning any UA in any case...we can improve the heuristics but they're not normative. Normative is if you style as focus-visible you match as focus-visible. We can do wahtever we want with heuristics but they're informative. We can't put heuristics that won't match actual definition of most browsers.<br> <dael> fantasai: I'm not sure what we're trying to do here. What's required is clear and this is just helpful hints when designing a UA.<br> <dael> emilio: When you focus and element inside a shadow tree a lot of state in the page reflects that. focus pseudo class and others. Issues is, for regular elements like DOM APIs, app dev returns shadow host. THat doesn't change if real active element is there. Doens't change what it is. Issue here is should we do same with css pseudo classes<br> <dael> emilio: I agree it could go either way. But it doesn't change if inner element should match focus-visible. If we spec it should bubble up and target dom apis all browsers should do<br> <Rossen_> ack fantasai<br> <dael> florian: Then are we saying it should style around the shadow host?<br> <dael> emilio: In order for bubble up to work you need to match is a special in your sheets. UA sheets match in all shadow scopes.<br> <dael> fantasai: Point of focus-visible was for UA to not have magic pseudo class that does something different<br> <dael> emilio: Right, this should apply to all retargetting like column-focus. Not magic like how it's not magic if you target inside the tree<br> <dael> florian: Does UA draw focus line around shadow root<br> <dael> emilio: Should not<br> <dael> florian: Then focus-visible should not. It's what focus-visible is for<br> <rego> about the heuristics, despite they're not normative, all implementations are following them, so they help to ensure interop on :focus-visible implementations<br> <dael> emilio: Right, but if you think in terms of built in control like date. You have inner element you focus. date is little editable fields for day, month, year. Inner focused is editable inside shadow root. In that case you want focus-visible to bubble so you get outline around text<br> <dael> emilio: Maybe add a way for shadow host to opt in. by default we shouldn't match<br> <tantek> regrets+<br> <dael> Rossen_: Don't feel we're ready to resolve. I suggest back to the issue and bring it back when we're ready<br> <dael> rego: Agree<br> <dael> rego: We should keep discussion on issue<br> <tantek> regrets+ Morgan<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5893#issuecomment-780716478 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 February 2021 17:23:29 UTC