-
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
Shadow DOM and autofocus="" #833
Comments
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:
|
I think autofocus should work only if the host was also focused. Otherwise, component users would be forced to avoid using components that uses A better behavior would be that when a component is focused and |
How would you then implement an autofocusable search widget? Say you have |
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 |
Are you suggesting that "autofocus" should be recursively determined? e.g.
|
@rniwa it's not exactly clear what you're proposing here. Currently |
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 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 So anyway, @rniwa’s proposal, as far as I can tell, is that components using |
Combining it with shadow root's |
Which is tracked by #2013 FWIW. |
Rough consensus at TPAC F2F:
|
And add |
cc @whatwg/documentation |
Documentation need recorded on MDN content roadmap — https://trello.com/c/OrG1iEf2/127-shadow-dom-api |
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? |
Agreed, that sounds like a good way to implement the proposal. |
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? |
In particular, in the current spec, if you put |
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. |
It occurs to me this might be a disruptive change for components that use So I think I'll add a fallback step so that if there is no descendant with |
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:
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 So now I'm thinking (2) would be better. Thoughts welcome. |
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.
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: