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

Upstream focus navigation behavior for `delegatesFocus` from W3C spec. #2013

Closed
bicknellr opened this issue Nov 4, 2016 · 13 comments

Comments

@bicknellr
Copy link

@bicknellr bicknellr commented Nov 4, 2016

The W3C's Shadow DOM spec modified sequential focus navigation behavior to take into account the state of the delegatesFocus flag given when creating ShadowRoots. This behavior should be brought into the WHATWG HTML spec.

@annevk annevk added the topic: shadow label Nov 7, 2016
@TakayoshiKochi

This comment has been minimized.

Copy link
Member

@TakayoshiKochi TakayoshiKochi commented Jul 20, 2017

Can someone assign me to this?

@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Jun 27, 2019

@rakina has started working on this, and it's great. See the auto-generated-by-GitHub links above for details.

Does anyone (especially @rakina) have thoughts on whether any of these should be landed independently, or all at once? I am glad @rakina is breaking up the work into small, easily reviewable pieces, but I am personally unsure whether we should land them separately or together.

@rniwa

This comment has been minimized.

Copy link
Collaborator

@rniwa rniwa commented Jun 27, 2019

We probably should land them all at once when either Gecko or WebKit successfully implements delegatesFocus in its engine. This area of the spec is hairy enough that we probably want to have the spec text vetted by another implementor. e.g. I'm still unclear about what exactly I'm implementing for the sequential focus navigation order between splitting of nodes into scopes & merging of scopes while dealing with all the random implementation complexity (e.g. option tab vs. tab) in WebKit.

@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Jun 27, 2019

Well, the reason I ask is that #4735 and its tests are pretty independent from delegatesFocus. But I guess implementers might want to just do everything at once.

@rniwa

This comment has been minimized.

Copy link
Collaborator

@rniwa rniwa commented Jun 27, 2019

@domenic : I think Blink, Gecko, and WebKit all more or less implement the interoperable focusing behavior (module browser difference in what is considered as focusable) across shadow boundaries correctly. What's unclear is all the details of integration with delegatesFocus.

@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Jun 27, 2019

Ah OK, in that case we can probably merge #4735 ahead of the others, assuming that the test results confirm that the results are indeed interoperable.

@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Jun 27, 2019

Well, I guess that has some delegatesFocus stuff in it too, sorry, I misunderstood. Nevermind!

@rakina

This comment has been minimized.

Copy link
Contributor

@rakina rakina commented Sep 20, 2019

At TPAC a few people notified me that they're interested in following the spec progress for this but weren't sure if they saw everything related to this, so here's a list of relevant links

List of related PRs:

  • Update sequential focus navigation to include shadow trees #4735
  • Add shadow host consideration for :focus selector #4731
  • Handle shadow host with delegatesFocus=true in Element.focus()/focusing steps #4796

Issues:

  • Focus delegation from shadow host should not behave like sequential focus navigation w3c/webcomponents#830
  • Should host with delegatesFocus true keep the previous focused element focused if it's a shadow-including descendant of the host? w3c/webcomponents#840

Not really related to delegatesFocus, but helps clear things up in the focus spec:

  • Define different types of "focusable" & remove "tabindex focus flag" #4768
  • Define DocumentOrShadowRoot.activeElement #4837
  • Define what tabIndex returns when the tabindex attribute is not set #4754
domenic added a commit to whatwg/dom that referenced this issue Sep 24, 2019
Fixes #367, i.e. the DOM part of
whatwg/html#2013. Further commits in HTML will
use this flag.
domenic added a commit that referenced this issue Sep 24, 2019
Part of #2013. Note that the delegates focus flag is not consulted.

Tests: web-platform-tests/wpt#17493
domenic added a commit to rakina/html that referenced this issue Sep 24, 2019
This defines an explicit list for the document's "sequential focus
navigation order", whose contents are defined to include elements in
shadow trees. Previously the contents of the sequential focus navigation
order were defined mostly implicitly, in the tabindex section.

This also expands the ordering requirements for sequential focus
navigation order to account for shadow trees and slotted elements.

Finally, this has a minor connection to delegatesFocus, in that it
excludes elements that are shadow hosts with delegatesFocus = true from
being focusable areas.

Part of whatwg#2013.

Tests: web-platform-tests/wpt#17523
domenic added a commit that referenced this issue Sep 24, 2019
This defines an explicit list for the document's "sequential focus
navigation order", whose contents are defined to include elements in
shadow trees. Previously the contents of the sequential focus navigation
order were defined mostly implicitly, in the tabindex section.

This also expands the ordering requirements for sequential focus
navigation order to account for shadow trees and slotted elements.

Finally, this has a minor connection to delegatesFocus, in that it
excludes elements that are shadow hosts with delegatesFocus = true from
being focusable areas.

Part of #2013.

Tests: web-platform-tests/wpt#17523
domenic added a commit to rakina/html that referenced this issue Sep 24, 2019
Define "focusable" more concretely, and as part of it, define special
types of focusability: click focusable and sequentially focusable.

As part of this, remove the "tabindex focus flag" because it can be
replaced with "focusable" and "focusable area", and was very confusing.

Part of whatwg#4607. Helps provide a basis for further work on whatwg#2013, but does
not directly contribute to any shadow DOM upstreaming.

This does not introduce any normative changes, but instead brings into
the spec behavior that was previously only in implementations, and makes
certain concepts explicit.
domenic added a commit that referenced this issue Sep 24, 2019
Define "focusable" more concretely, and as part of it, define special
types of focusability: click focusable and sequentially focusable.

As part of this, remove the "tabindex focus flag" because it can be
replaced with "focusable" and "focusable area", and was very confusing.

Part of #4607. Helps provide a basis for further work on #2013, but does
not directly contribute to any shadow DOM upstreaming.

This does not introduce any normative changes, but instead brings into
the spec behavior that was previously only in implementations, and makes
certain concepts explicit.
@rniwa

This comment has been minimized.

Copy link
Collaborator

@rniwa rniwa commented Oct 12, 2019

As far as I've reviewed PRs, things are looking good. I've implemented the new tabIndex behavior in https://bugs.webkit.org/show_bug.cgi?id=199606 and delegatesFocus flag is getting added in https://bugs.webkit.org/show_bug.cgi?id=166484.

domenic added a commit that referenced this issue Oct 16, 2019
This is the last piece of #2013. Incoporating support for
delegates-focus shadow roots into the focusing steps impact the behavior
of programmatic and click focus. (Sequential focus navigation was
handled in d19d963.)

Tests: web-platform-tests/wpt#18035
@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Oct 16, 2019

Hooray!! Spec updated! @rakina, can you file tracking issues for Gecko and Blink? Ideally you'd include pointers to all the new spec sections, and especially the new web platform tests, but for Blink I'll leave it to you.

@rniwa, it sounds like you've got things fully tracked on the WebKit side, but let us know if you'd appreciate any such bug.

@domenic domenic closed this Oct 16, 2019
@rakina

This comment has been minimized.

Copy link
Contributor

@rakina rakina commented Oct 16, 2019

@rniwa

This comment has been minimized.

Copy link
Collaborator

@rniwa rniwa commented Oct 16, 2019

Note that the new behavior has been fully implemented in WebKit:
:focus selector change: https://trac.webkit.org/r250788
delegatesFocus flag: https://trac.webkit.org/r251043

Let me know if you find any differences with WebKit's implementation with yours / spec.

@rakina

This comment has been minimized.

Copy link
Contributor

@rakina rakina commented Oct 16, 2019

zcorpan added a commit that referenced this issue Nov 6, 2019
Part of #2013. Note that the delegates focus flag is not consulted.

Tests: web-platform-tests/wpt#17493
zcorpan added a commit that referenced this issue Nov 6, 2019
This defines an explicit list for the document's "sequential focus
navigation order", whose contents are defined to include elements in
shadow trees. Previously the contents of the sequential focus navigation
order were defined mostly implicitly, in the tabindex section.

This also expands the ordering requirements for sequential focus
navigation order to account for shadow trees and slotted elements.

Finally, this has a minor connection to delegatesFocus, in that it
excludes elements that are shadow hosts with delegatesFocus = true from
being focusable areas.

Part of #2013.

Tests: web-platform-tests/wpt#17523
zcorpan added a commit that referenced this issue Nov 6, 2019
Define "focusable" more concretely, and as part of it, define special
types of focusability: click focusable and sequentially focusable.

As part of this, remove the "tabindex focus flag" because it can be
replaced with "focusable" and "focusable area", and was very confusing.

Part of #4607. Helps provide a basis for further work on #2013, but does
not directly contribute to any shadow DOM upstreaming.

This does not introduce any normative changes, but instead brings into
the spec behavior that was previously only in implementations, and makes
certain concepts explicit.
zcorpan added a commit that referenced this issue Nov 6, 2019
This is the last piece of #2013. Incoporating support for
delegates-focus shadow roots into the focusing steps impact the behavior
of programmatic and click focus. (Sequential focus navigation was
handled in d19d963.)

Tests: web-platform-tests/wpt#18035
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
You can’t perform that action at this time.