[Shadow] Focus on shadow host should slide to its inner focusable node (delegatesFocus)

[TakayoshiKochi]

Migrated from https://www.w3.org/Bugs/Public/show_bug.cgi?id=28054
Takayoshi Kochi 2015-02-19 01:46:33 UTC

When a shadow host which is normally unfocusable (e.g. <div>), has focusable elements
(e.g. <input>) in its shadow tree, focus()ing on the host, or when tabindex attribute is
set on the host and keyboard navigation reaches the host, the focusing behavior should not
stop on the host but slide to its inner shadow tree if any elements in the shadow tree is focusable.

Without this default behavior, if a developer wants to emulate e.g. with a shadow DOM, some tricky workarounds are needed or at least exposing HTML "tab focusable flag" on an element.

This is not specified in the shadow DOM spec as of now, but this behavior should be
more convenient for a component developer.

Example1:

 <input id="input-A">
 <div id="host" tabindex="0">
    | #shadow
    |   <input id="inner">
 </div>
 <input id="input-B">

In this case, $("host").focus() or hitting TAB from #input-A, focus should move to #inner, rather than #host.
In reverse order, hitting Shift + TAB from #input-B should move to #inner, then #input-A.
This is the new behavior that this bug is proposing.

Example2:

<input id="input-A">
<div id="host" tabindex="0">
  | #shadow
  |   <div>... Some widget here, no focusable element...</div>
</div>
<input id="input-B">

In this case, $("host").focus() or hitting TAB from #input-A, focus should move to #host.
This is an existing behavior.

Example3:

<input id="input-A">
<div id="widget" tabindex="0">
   <input id="inner">
</div>
<input id="input-B">

In this case, $("widget").focus() or hitting TAB from #input-A, focus should move to #widget.
This is also an existing behavior.

---

This came up from conversation with Ian Hickson over the shadow DOM tabindex focus behavior document.

[rniwa]

Moving the focus automatically to an inner-focusable element makes sense to me.

Now, once we made the focus to be automatically delegated as proposed on this issue, I can't think of a good reason to keep delegatesFocus flag. It appears to me that, the only useful flag value is false to turn off the delegation in that world but we could simply not delegating the focus when the shadow DOM only contains elements without tabindex or a negative tabindex to address the same use case.

[annevk]

I could see that for <video> you might want to focus the entire element to activate it easily with a keyboard (and start playing), but still go through it to access individual controls.

But again, since focus in general is poorly explained, it's hard to figure out if delegatesFocus is the primitive or just added complexity.

[rniwa]

That's a fair point although that could be easily done by wrapping the shadow DOM contents with <div tabindex=0>~</div> as well.

[annevk]

So you mean that tabindex=0 on the custom element has no effect? But we know it has an effect on builtin elements today.

[rniwa]

Oh, no. I meant that inside the shadow DOM. If you wanted to let the host focused, you could emulate that inside the shadow DOM by wrapping the shadow DOM content in a focusable element. As far as the outer DOM is considered, the host element is the one that has the focus so it won't be able to tell the difference. It's not the most elegant solution but it works...

[annevk]

I understood you meant inside the shadow DOM. Though I didn't understand you want this multi-level focus thing. Sounds tricky.

[hayatoito]

Looks this issue, #105, and issue #126, are almost the same topic. #126 is newer one and has a concrete proposal. Can we merge #105 with #126?

[hayatoito]

Let me merge without the permissions. I'll close this issue.
You can continue the discussion in #126, where the proposal covers this kind of "Moving the focus automatically".