Re: [w3c/webcomponents] Focus delegation from shadow host should not behave like sequential focus navigation (#830)

> > Yeah, both of these are highly problematic. What if we let delegatesFocus take an ID as in: delegatesFocus: "foo" and pick the first element with that ID? ID is unique per shadow tree so there is no ambiguity. But this probably needs to be used only in the case of an explicit focus call or when the user clicks somewhere on a custom element but not elements within its shadow tree themselves.
>
> This might have some problems with slotted elements. What if we use the actual elements instead? So like `host.setFocusDelegationTarget(el)`? The default behavior if the focus delegation target is not set would be to focus the first focusable thing in flat-tree order, but if it's set it will always focus on el.

Indeed, an explicit setter might better although it brings its own can of worms by allowing random node outside of shadow host's flat tree to be specified. However, that might not matter. We can reject whatever node which is not a focusable element in the flat tree at the time of focusing, and treat as if it's not specified in which case we can fallback to the default (maybe the first focusable element).

Now that I've been thinking about this issue for a while, I'm pretty convinced that mouse based focusing & keyboard based focusing need to be treated differently. In the case of keyboard based sequential focus navigation, we should simply find the first element with the `tabIndex` order and focus that for the reasons @hayatoito stated above. So regardless of whether we add this setter or not, the keyboard-based sequential focus navigation should continue to use `tabIndex` order to pick which element gets the delegation.

In the case of mouse based focusing, however, it's unclear to me if a component can specify which element to be focused priori. As I [stated above](https://github.com/w3c/webcomponents/issues/830#issuecomment-526453182), some components may need to make a decision knowing where the user had clicked to trigger such focusing. I *think* a component can do this by listening to `focus` event on the host element and re-focusing to whichever element they want to delegate focus.

As I've [noted multiple times](https://github.com/w3c/webcomponents/issues/830#issuecomment-526453182) above, we don't want `element.focus()` to depend upon `tabIndex` order since what is considered keyboard focusable is implementation dependent and we want JS API to be as interoperable as possible. This would mean that the main point of `host.setFocusDelegationTarget` is to specify what gets focused when the script manually calls `element.focus`. Note this too needs to have a fallback option when the element the script had set isn't in the flat tree of the shadow host. So we'd have to decide what would happen in that case as well (probably the first clickable element in the flat tree).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/830#issuecomment-526638143