Skip to content
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

Merged
merged 10 commits into from
Sep 24, 2019
Merged

Add shadow host consideration for :focus selector #4731

merged 10 commits into from
Sep 24, 2019

Conversation

rakina
Copy link
Member

@rakina rakina commented Jun 25, 2019

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 )

source Show resolved Hide resolved
source Show resolved Hide resolved
Copy link
Member

@domenic domenic left a 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.

source Show resolved Hide resolved
source Show resolved Hide resolved
@domenic domenic added addition/proposal New features or enhancements topic: custom elements Relates to custom elements (as defined in DOM and HTML) topic: focus labels Jun 27, 2019
source Outdated Show resolved Hide resolved
Copy link
Member

@domenic domenic left a 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 ;).)

source Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@annevk
Copy link
Member

annevk commented Jun 27, 2019

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.)

@rakina
Copy link
Member Author

rakina commented Jun 27, 2019

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?

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.

@annevk
Copy link
Member

annevk commented Jun 27, 2019

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.

@rniwa
Copy link

rniwa commented Jun 27, 2019

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?

shadowRoot.activeElement would still find the slot, and :focus-within would match the slot. Conceptually, :focus only applies to the very element which is the focus anchor at that moment.

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, document.activeElement and shadowRoot.activeElement would still refer to its shadow host. If :focus is false on that shadow host, it basically means the element has a shadow root.

See WICG/webcomponents#804 for some discussions.

But perhaps we should first spec the status quo and fix it as an independent effort.

@domenic domenic self-assigned this Jul 2, 2019
Copy link
Member

@domenic domenic left a 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

source Show resolved Hide resolved
@rniwa
Copy link

rniwa commented Jul 30, 2019

The current PR would mean that :focus would match whenever a shadow tree contains an element and the shadow root itself has delegatesFocus. I still think that might be bad and we may want to make :focus always apply whenever element's shadow root contains a focused element.

However, the current PR matches the existing implementation (Chrome) and other implementations (WebKit & Gecko) don't match :focus on these cases so it's probably okay to keep this PR as is, and approach this issue in a separate PR.

@domenic
Copy link
Member

domenic commented Jul 30, 2019

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) ?

@domenic domenic added the do not merge yet Pull request must not be merged per rationale in comment label Jul 30, 2019
@smaug----
Copy link

smaug---- commented Aug 30, 2019

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.

Copy link

@smaug---- smaug---- left a 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.

@rakina
Copy link
Member Author

rakina commented Sep 9, 2019

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.

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?

@rakina rakina changed the title Add delegatesFocus consideration for :focus selector Add shadow host consideration for :focus selector Sep 20, 2019
@rakina
Copy link
Member Author

rakina commented Sep 20, 2019

This was discussed in TPAC web components session, and we decided to make the host match :focus too if it shadow tree contains a focused element. Updated the spec part here, will update the WPT PR too.

@domenic domenic removed the do not merge yet Pull request must not be merged per rationale in comment label Sep 24, 2019
Copy link
Member

@domenic domenic left a 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!

@domenic domenic dismissed smaug----’s stale review September 24, 2019 06:23

Changes addressed at TPAC

@domenic domenic merged commit 500f4fe into whatwg:master Sep 24, 2019
domenic pushed a commit to web-platform-tests/wpt that referenced this pull request Sep 24, 2019
@annevk
Copy link
Member

annevk commented Sep 25, 2019

Can someone file the relevant implementation bugs too?

@domenic
Copy link
Member

domenic commented Sep 26, 2019

My plan was to late until the last PR in the series landed, which should be today

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Sep 26, 2019
…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
xeonchen pushed a commit to xeonchen/gecko that referenced this pull request Sep 27, 2019
…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
@rniwa
Copy link

rniwa commented Oct 1, 2019

@rniwa
Copy link

rniwa commented Oct 4, 2019

It's unfortunate that this got landed with a test (shadow-dom/focus/focus-selector-delegatesFocus.html), which relies on delegatesFocus. Also, it doesn't seem to test enough edge cases. I'll add more tests in my WebKit patch.

gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Oct 4, 2019
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Oct 4, 2019
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Oct 5, 2019
…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
@rakina
Copy link
Member Author

rakina commented Oct 7, 2019

It's unfortunate that this got landed with a test (shadow-dom/focus/focus-selector-delegatesFocus.html), which relies on delegatesFocus. Also, it doesn't seem to test enough edge cases. I'll add more tests in my WebKit patch.

It tests both values for delegatesFocus though? Do you mean it might not work in some browsers because they don't actually have that option? I thought they would just ignore that in that case - if not, oops, sorry D:

@rniwa
Copy link

rniwa commented Oct 7, 2019

Well, delegatesFocus is a new feature not implemented in any browser but Chrome whereas :focus and shadow DOM is a feature implemented by all browsers. Ideally, these things are independently of one another so that the test for :focus doesn’t depend on delegatesFocus.

@rniwa
Copy link

rniwa commented Oct 7, 2019

Alright, this new behavior has been implemented as of https://trac.webkit.org/changeset/250788.

@domenic
Copy link
Member

domenic commented Oct 8, 2019

The test doesn't behave on it. It in fact explicitly tests that delegatesFocus has no effect on the behavior.

@rniwa
Copy link

rniwa commented Oct 8, 2019

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 delegatesFocus is the problem. Since it's a new feature, there should have been a separate test that doesn't test or mention anything about delegatesFocus.

@domenic
Copy link
Member

domenic commented Oct 8, 2019

Ok, we'll have to agree to disagree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements topic: custom elements Relates to custom elements (as defined in DOM and HTML) topic: focus
Development

Successfully merging this pull request may close these issues.

5 participants