-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Add shadow host consideration for :focus selector #4731
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Editorial comments aside, I think this works. The tests in https://github.com/web-platform-tests/wpt/pull/17493/files seem correct, and here is my walkthrough of a couple of them:
Delegated
<div id="outer">
#shadow delegatesFocus = true
<div id="mid">
#shadow delegatesFocus = true
<div id="inner" tabindex="0">
inner.focus()
- inner has the focus because it is the currently focused area of the top-level browsing context
- mid has the focus because its shadow root is not null, its shadow root's delegates focus is true, and its shadow root is the root of inner
- outer has the focus because its shadow root is not null, its shadow root's delegates focus is true, and its shadow root is the root of mid
No delegation
<div id="outer">
#shadow delegatesFocus = true
<div id="mid">
#shadow delegatesFocus = false
<div id="inner" tabindex="0">
inner.focus()
- inner has the focus because it is one of the elements listed in the focus chain of the currently focused area of the top-level browsing context
- mid does not have the focus, because its shadow root's delegates focus is false, and it is not listed in the focus chain of inner. (As Rakian says, focus chains basically only contain the parent BC container elements)
- outer does not have the focus because it is not the root of any element that has the focus, and it is not listed in the focus chain of inner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with nits. (If we were in different timezones I would fix them myself to avoid overnight latency, but since we are in the same timezone, I will let you fix them. Lucky you ;).)
Is there no interaction with the composed tree here? In particular if there's a focused slotted element nothing encompassing the slot in the shadow tree gets/has to know about this? (I'm not entirely sure what the answer should be, but it would be good to add another test for this scenario as I only see it being covered that the host does not get focus, which does seem correct from an encapsulation perspective.) |
Yes, if a slotted element is focused, nothing in the shadow tree gets to know about it, since it's not actually in the shadow tree. |
So if you have a focusable div in a shadow tree that contains a slot through which you slot another focusable div and you focus the latter, the focusable div in the shadow tree won't be focused? I guess that makes sense given how nested focus structures work outside shadow trees, but it'd be good to add asserts. |
But now thinking about this more carefully, this may leak the existence of shadow root in that if there is a focused element inside a shadow tree, See WICG/webcomponents#804 for some discussions. But perhaps we should first spec the status quo and fix it as an independent effort. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may be misreading, but I think the PR works in the following way:
<div id="outer">
#shadow delegatesFocus = true
<div id="inner1" tabindex="0">
<div id="inner2" tabindex="0">
inner2.focus();
inner1.matches(":focus");
This seems a bit strange. Is this intentional? I don't think I see any tests for it.
Draft commit message:
Handle elements inside delegatesFocus shadow trees for :focus
Part of #2013.
Tests: https://github.com/web-platform-tests/wpt/pull/17493
The current PR would mean that However, the current PR matches the existing implementation (Chrome) and other implementations (WebKit & Gecko) don't match |
Thanks. I agree with that approach and see no problems with revisiting the issue going forward. Can you confirm if WebKit still opposes merging this PR, and its dependency of whatwg/dom#768, or has that changed since whatwg/dom#768 (comment) ? |
Why would delegatesFocus affect to :focus in any way? Feels really weird. As rniwa hinted, we shouldn't expose the existence of shadowroot, so host should get :focus when it shows up as the .activeElement in its context. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no reasoning for this change.
It does feel a little weird for the behavior to differ between hosts with delegateFocus vs not. I'm not quite sure about the past reasoning for this behavior, maybe @hayatoito knows more? Would you rather this PR change the behavior so that both hosts with & without delegatesFocus will match :focus when an element in its shadow tree is focused then? |
This was discussed in TPAC web components session, and we decided to make the host match |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This matches the TPAC consensus, and has tests; merging!
Can someone file the relevant implementation bugs too? |
My plan was to late until the last PR in the series landed, which should be today |
…osts, a=testonly Automatic update from web-platform-tests CSS: :focus selector effects on shadow hosts Follows whatwg/html#4731. -- wpt-commits: 0693b81665fcc5a7258535e4403b748a810730ae wpt-pr: 17493
…osts, a=testonly Automatic update from web-platform-tests CSS: :focus selector effects on shadow hosts Follows whatwg/html#4731. -- wpt-commits: 0693b81665fcc5a7258535e4403b748a810730ae wpt-pr: 17493
It's unfortunate that this got landed with a test (shadow-dom/focus/focus-selector-delegatesFocus.html), which relies on |
…osts, a=testonly Automatic update from web-platform-tests CSS: :focus selector effects on shadow hosts Follows whatwg/html#4731. -- wpt-commits: 0693b81665fcc5a7258535e4403b748a810730ae wpt-pr: 17493 UltraBlame original commit: 319b49b753b936cafa788a116ebd3707d9dad2de
…osts, a=testonly Automatic update from web-platform-tests CSS: :focus selector effects on shadow hosts Follows whatwg/html#4731. -- wpt-commits: 0693b81665fcc5a7258535e4403b748a810730ae wpt-pr: 17493 UltraBlame original commit: 319b49b753b936cafa788a116ebd3707d9dad2de
…osts, a=testonly Automatic update from web-platform-tests CSS: :focus selector effects on shadow hosts Follows whatwg/html#4731. -- wpt-commits: 0693b81665fcc5a7258535e4403b748a810730ae wpt-pr: 17493 UltraBlame original commit: 319b49b753b936cafa788a116ebd3707d9dad2de
It tests both values for |
Well, |
Alright, this new behavior has been implemented as of https://trac.webkit.org/changeset/250788. |
The test doesn't behave on it. It in fact explicitly tests that delegatesFocus has no effect on the behavior. |
The fact it tests whether the behavior of it depends on |
Ok, we'll have to agree to disagree. |
A bit related to #2013 and whatwg/dom#768. Will send a separate PR that updates the sequential navigation parts later.
Tests: web-platform-tests/wpt#17493
/acknowledgements.html ( diff )
/infrastructure.html ( diff )
/semantics-other.html ( diff )