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

Shadow DOM and autofocus="" #833

Closed
annevk opened this issue Mar 8, 2016 · 21 comments · Fixed by #6990
Closed

Shadow DOM and autofocus="" #833

annevk opened this issue Mar 8, 2016 · 21 comments · Fixed by #6990
Labels
impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation topic: focus topic: shadow Relates to shadow trees (as defined in DOM)

Comments

@annevk
Copy link
Member

annevk commented Mar 8, 2016

Presumably autofocus="" should work in shadow trees. As far as I can tell the main modification needed here is to "inserted into a document" which needs to be broadened to include shadow trees.

Paging @hayatoito @smaug---- @rniwa.

@annevk annevk added the topic: shadow Relates to shadow trees (as defined in DOM) label Mar 8, 2016
@hayatoito
Copy link
Member

We had an issue here, WICG/webcomponents#97, but it looks I already closed it.

If we support autofocus="" in a shadow tree, we should define a global order between nodes in a composed tree of node trees so that we cal tell the first "autofocus" element in a composed tree of node trees.

That can be defined as:

  • If node A and node B are in the same node tree, just use the tree order in the node tree.
  • Otherwise, A comes before B if A's home subtree is preceding B's home subtree in a composed tree of node trees.

@rniwa
Copy link

rniwa commented May 5, 2016

I think autofocus should work only if the host was also focused. Otherwise, component users would be forced to avoid using components that uses autofocus attribute in its shadow tree.

A better behavior would be that when a component is focused and delegatesFocus is true, the focus goes to the element with autofocus attribute.

@annevk
Copy link
Member Author

annevk commented May 9, 2016

How would you then implement an autofocusable search widget? Say you have <search-widget> as custom element and inside it you have some controls, one of which needs to get focus during page load.

@rniwa
Copy link

rniwa commented May 9, 2016

I don't think a component can make that decision since there could be another element that needs to be auto-focused. Whoever uses the component should set autofocus on search-widget element.

@hayatoito
Copy link
Member

hayatoito commented May 11, 2016

Are you suggesting that "autofocus" should be recursively determined?

e.g.

let e = find_autofocus(document);
if (e != null)
  autofocusit(e);

function find_autofocus(a) {
  let e = find_first_auto_focusable_element_in_the_same_tree(a);
  if (e == null) return null;  
  if (e is shadow_host && e's delegatesFocus is true) {
    return find_autofocus(e.shadowroot)
  } else {
    return e;
  }
}


@annevk
Copy link
Member Author

annevk commented Sep 5, 2017

@rniwa it's not exactly clear what you're proposing here. Currently autofocus only applies to button, input, select, and textarea. Rather than inventing a new model for autofocus, it seems much easier to allow components to use autofocus. You can simply avoid using components that abuse it or don't allow you to configure whether it's used.

@tabatkins
Copy link
Contributor

I think @rniwa's point is that it sucks if either (a) the component self-determines that it wants to be auto-focused, or (b) the component has to invent its own attribute that means "autofocus" and then respond to that to put a real autofocus on its internal input.

Separately, if a component has a particular input among its shadow children that it wants to receive focus by default, it has to wire all that by itself.

Part of the reasoning for custom elements is making them, as much as possible/feasible, indistinguishable from normal elements. Making it hard to properly handle focus, and impossible to use the autofocus attribute on, isn't following this goal.


So anyway, @rniwa’s proposal, as far as I can tell, is that components using delegatesFocus (which makes them "atomic" to the light dom's focus tree, more or less) should be able to use autofocus internally to designate which of its focusable elements receive the automatic focus (rather than, as currently specified, it always being the first focusable element). Then autofocus on the component itself will also work, by automatically focusing the component, and then delegating that to the designated shadow element.

@annevk
Copy link
Member Author

annevk commented Sep 6, 2017

Combining it with shadow root's delegatesFocus (recursive lookup, presumably) seems reasonable. This will depend on @TakayoshiKochi's work then.

@annevk
Copy link
Member Author

annevk commented Sep 13, 2017

Which is tracked by #2013 FWIW.

@rniwa
Copy link

rniwa commented Oct 25, 2018

Rough consensus at TPAC F2F:

  • autofocus global attribute so that it can be specified on any focusable element
  • As I suggested before, when a component is focused and delegatesFocus is true, the focus goes to the element with autofocus attribute.

@xfq
Copy link
Contributor

xfq commented Oct 25, 2018

And add autofocus global attribute for SVG too?

@sideshowbarker sideshowbarker added the impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation label Oct 26, 2018
@sideshowbarker
Copy link
Contributor

cc @whatwg/documentation

@chrisdavidmills
Copy link

Documentation need recorded on MDN content roadmap — https://trello.com/c/OrG1iEf2/127-shadow-dom-api

@domenic
Copy link
Member

domenic commented Sep 19, 2019

As I suggested before, when a component is focused and delegatesFocus is true, the focus goes to the element with autofocus attribute.

I hope "when a component is focused" here is shorthand for "when a component is autofocused"?

If so, this should be relatively easy to implement on top of @tkent-google's merged changes to autofocus and @rakina's not-yet-merged integration of delegatesFocus.

@rakina
Copy link
Member

rakina commented Sep 26, 2019

As I suggested before, when a component is focused and delegatesFocus is true, the focus goes to the element with autofocus attribute.

I hope "when a component is focused" here is shorthand for "when a component is autofocused"?

If so, this should be relatively easy to implement on top of @tkent-google's merged changes to autofocus and @rakina's not-yet-merged integration of delegatesFocus.

Yeah, probably we can just use a new "autofocus" focus trigger for the focusing steps at https://whatpr.org/html/4796/1ab7c86...ea97f92/interaction.html#focus-processing-model, and delegate the focus to the first focusable area with autofocus in the host's flat tree?

@domenic
Copy link
Member

domenic commented Sep 27, 2019

Yeah, probably we can just use a new "autofocus" focus trigger for the focusing steps at https://whatpr.org/html/4796/1ab7c86...ea97f92/interaction.html#focus-processing-model, and delegate the focus to the first focusable area with autofocus in the host's flat tree?

Agreed, that sounds like a good way to implement the proposal.

@domenic
Copy link
Member

domenic commented Aug 23, 2021

It seemed like we had consensus on this but never went ahead and wrote up the spec PR/etc. I'm willing to do the spec PR if someone else does the tests and we have implementer interest. @rniwa @mfreed7 @smaug---- any thoughts?

@domenic
Copy link
Member

domenic commented Aug 23, 2021

In particular, in the current spec, if you put autofocus on a delegatesFocus = true shadow root, then the autofocus algorithm will focus the first flat-tree-descendant focusable area. But what we want is to find the first flat-tree-descendant with the autofocus attribute.

@rniwa
Copy link

rniwa commented Aug 23, 2021

In particular, in the current spec, if you put autofocus on a delegatesFocus = true shadow root, then the autofocus algorithm will focus the first flat-tree-descendant focusable area. But what we want is to find the first flat-tree-descendant with the autofocus attribute.

Right. WebKit doesn't have autofocus attribute implemented for non-form-control element so we need to update our implementation first but implementing this new behavior sounds good to me.

@domenic
Copy link
Member

domenic commented Aug 25, 2021

It occurs to me this might be a disruptive change for components that use delegatesFocus but don't put autofocus on any of their descendants. That is, it basically changes the story for components to "if you use delegatesFocus, you must put autofocus on a descendant; otherwise when people try to autofocus your control, it won't work."

So I think I'll add a fallback step so that if there is no descendant with autofocus, it'll just choose the first focusable element. Let me know if that sounds like a bad idea.

@domenic
Copy link
Member

domenic commented Aug 25, 2021

Sigh. I'm having second thoughts now about my #833 (comment) . I might have confused the issue back then.

In particular I am wondering about two models:

  1. Whenever a delegatesFocus shadow host is autofocused, focus goes to the first flat-tree child with autofocus specified (if one exists).
  2. Whenever a delegatesFocus shadow host is focused in any way, focus goes to the first flat-tree child with autofocus specified (if one exists).

I don't recall what we discussed at TPAC back in the day, but @rniwa's summary indicates something more like (2). I then countered to propose (1), which people seem to go along with. But I can't really remember my reasoning...

In particular I worry a bit about (1) because it creates the opportunity for controls to behave differently depending on how they are focused. I.e., if the user clicks on a control, or a developer calls el.focus(), it will not take into account child autofocus attributes; but if we do <my-el autofocus>, it will.

So now I'm thinking (2) would be better. Thoughts welcome.

domenic added a commit that referenced this issue Aug 25, 2021
Now, when focusing a shadow host with delegates focus set, we try to focus the first focusable area with the autofocus attribute set, instead of just the first focusable area.

Closes #833.
domenic added a commit that referenced this issue Oct 13, 2021
Now, when focusing a shadow host with delegates focus set, we try to focus the first focusable area with the autofocus attribute set, instead of just the first focusable area. (If no focusable area has autofocus set, then we use the first one, like before.)

Closes #833.
dandclark pushed a commit to dandclark/html that referenced this issue Dec 4, 2021
Now, when focusing a shadow host with delegates focus set, we try to focus the first focusable area with the autofocus attribute set, instead of just the first focusable area. (If no focusable area has autofocus set, then we use the first one, like before.)

Closes whatwg#833.
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
Now, when focusing a shadow host with delegates focus set, we try to focus the first focusable area with the autofocus attribute set, instead of just the first focusable area. (If no focusable area has autofocus set, then we use the first one, like before.)

Closes whatwg#833.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation topic: focus topic: shadow Relates to shadow trees (as defined in DOM)
Development

Successfully merging a pull request may close this issue.

9 participants