Focus Navigation for slots

[rniwa]

We should update the section 6.2 Focus Navigation to reflect the discussion we had during TPAC last year.

I think what we want is akin to putting nodes inside a shadow DOM and a slot into its own nested browsing context. We should probably edit the HTML spec to create some sort of scoping mechanism, and make shadow DOM / slot element / browsing context use that concept.

[rniwa]

Could @hober or @annevk refactor the HTML spec as needed?

[hayatoito]

I'm interested in how this new feature would interact with the proposal in #126.

If either of them is an backward incompatible feature, we can not ship Shadow DOM v1 unless both are resolved.

@TakayoshiKochi
Could you lead the discussion? I'd like to know how we should handle the proposal in issue #126.

[rniwa]

I don't think they're incompatible with one another since we still need to define the behavior when delegateFocus is missing.

[hayatoito]

I guess @TakayoshiKochi has an opinion about this.
To me, they look apparently relevant if deleteFocus is enabled since either of them tries to define how tab focus navigation should work.

[TakayoshiKochi]

The discussion at TPAC was that basically we navigate focusable elements via TAB presses in a way that those within the same shadow root including distributed nodes are grouped, and in order of composed tree?

e.g.

<my-nameinput>
    <#shadow-root>
         Firstname: <slot name="firstname"></slot>
         Lastname: <slot name="lastname"></slot>
    </#shadow-root>
    <input id="first" slot="firstname">
    <input id="last" slot="lastname">
</my-nameinput>

will be rendered as

<my-nameinput>
     Firstname: <input id="first">
     Lastname: <input id="last">
</my-nameinput>

But if the order in the #shadow-root is flipped, rendering will be

<my-nameinput>
     Lastname: <input id="last">
     Firstname: <input id="first">
</my-nameinput>

With the current spec, TAB navigation order is fixed for both, #first -> #last, as in the order of
the document DOM tree. But preferably, the order should be #first -> #last for the former and #last -> #first for the latter.

Is this the bottomline?
I feel we can define this without nested browsing context, just with composed tree.

(but once tabIndex is involved, things may get complicated, like #126)

[rniwa]

Right, we want #first -> #last for the former and #last -> #first for the latter.

We're definitely not defining a nested browsing context because that'd be a wrong semantics. The reason I bring that up is that we need some sort of grouping/scoping mechanism for each shadow root as well as each slot (e.g. if tabindex was set on #first and #last, that shouldn't affect the order by which they're tab-focused). Since the HTML5 spec currently treats elements in each nested browsing context as if it were in such a scope, we should refactor the spec to extract that concept and make the concept of browsing context use it instead of the focus navigation section directly referring to browsing context. I've already asked @hober to do this and it looks like @LJWatson made w3c/html#44 to track this.

[rniwa]

Let's say we have the following DOM (nobody should be setting tabindex like this here but I can't come up with a better example for now):

<contect-card>
    Name first: <input id="first" slot="name" tabindex="1">
    Middle name: <input id="middle" slot="name" tabindex="4">
    Last name: <input id="last" slot="name" tabindex="2"><br>
    Email: <input id="email" tabindex="3">
</contect-card>
<input id="search" type="search" tabindex="5">

and let's say contect-card's shadow DOM is defined as follows:

<dl>
    <dt>Email</dt>
    <dd><slot name="email"></slot></dd>
    <dt>Name</dt>
    <dd><slot name="name"></slot></dd>
</dl>

Then the composed three will look like

<my-nameinput>
    <dl>
        <dt>Email</dt>
        <dd><input id="first" slot="name" tabindex="1"
        ><input id="middle" slot="name" tabindex="4"
        ><input id="last" slot="name" tabindex="2"></dd>
        <dt>Name</dt>
        <dd><input id="email" tabindex="3"></dd>
    </dl>
</my-nameinput>
<input id="search" type="search" tabindex="5">

In this composed tree, the tab focusing order should be #first, #last, #middle, #email, then #search because shadow root and slot each defines its own focus scope/group.

[LJWatson]

@rniwa

This approach makes sense I think. Just thinking through some of the possibilities though...

If the DOM looked like this instead:

<contect-card>
    Name first: <input id="first" slot="name" tabindex="1">
    Middle name: <input id="middle" slot="name">
    Last name: <input id="last" slot="name"><br>
    Email: <input id="email" tabindex="3">
</contect-card>

Using the same shadow DOM you described, leading to the following composed tree:

<my-nameinput>
    <dl>
        <dt>Name</dt>
        <dd><input id="first" slot="name" tabindex="1">
        ><input id="middle" slot="name">
        ><input id="last" slot="name"></dd>
        <dt>Email</dt>
        <dd><input id="email" tabindex="3"></dd>
    </dl>
</my-nameinput>

The tab order would be #first, #middle, #last, then #email? In other words would elements without tabindex also be scoped to the slot and/or shadow root?

[rniwa]

Yes. Just like nested browsing context, elements will be ordered first by the descending order of tabindex value and then the tree order.

Just as another example, if the DOM looked like:

<contect-card>
    Name first: <input id="first" slot="name" tabindex="2">
    Middle name: <input id="middle" slot="name">
    Last name: <input id="last" slot="name" tabindex="1"><br>
    Email: <input id="email" tabindex="3">
</contect-card>

and the composed tree looked like:

<contect-card>
    <dl>
        <dt>Name</dt>
        <dd><input id="first" slot="name" tabindex="2">
        ><input id="middle" slot="name">
        ><input id="last" slot="name" tabindex="1"></dd>
        <dt>Email</dt>
        <dd><input id="email" tabindex="3"></dd>
    </dl>
</contect-card>

instead, then the focus navigation order will be #last, #first, #middle, then #email.

[hayatoito]

I like an idea that each slot has a scope as well as a component tree has.
I think this approach is doable and spec-able. I support it.

A couple of thoughts:

• I recommend not to use the term of "order of the composed tree" because it does not reflect the approach correctly.
• I recommend not to use the composed tree to explain the order because the composed tree is the result of flatting scopes. Its difficult to see in what order elements are traversed there because a tabindex should be encapsulated in each scope.
• It would be better to consider the case where a slot is assigned to another slot.
• The following is the behavior what I am expecting, using more comprehensive tree of trees:

e.g.

document tree:

  <input id=i0 tabindex=0></input>
  <x-foo tabindex=0>
    <input id=i2 slot=s1 tabindex=2></input>
    <input id=i1 slot=s1 tabindex=1></input>
  </x-foo>

<x-foo>'s shadow tree:

  <x-bar tabindex=4>
    <input id=j1 slot=s2 tabindex=1></input>
    <slot id=s1 name=s1 slot=s2></slot>
    <input id=j0 slot=s2 tabindex=0></input>
    <input id=j2 slot=s2 tabindex=2></input>
  </x-bar>
  <input id=j4 tabindex=4></input>
  <input id=j3 tabindex=3></input>

<x-bar>'s shadow tree:

  <input id=k0 tabindex=0></input>
  <slot id=s2 name=s2></slot>
  <input id=k1 tabindex=1></input>

The sequential focus navigation in each scope will be:

• document tree: [i0 -> [x-foo]]
• x-foo's shadow tree: [j3 -> [x-bar] -> j4]
• slot #s1: [i1 -> i2]
• x-bar's shadow tree: [k1 -> k0 -> [s2]]
• slot #s2: [j1 -> j2 -> [s1] -> j0]

Thus, if flattened, the (global) sequential focus navigation would be: [i0 -> j3 -> k1 -> k0 -> j1 -> j2 -> i1 -> i2 -> j0 -> j4]

Additional question: Should we honor the tabindex value of a slot element? The motivation is to control where a slot's scope is inserted in the enclosing scope. e.g. We might want to control where s1's scope, [s1], is inserted in [s2].

In the example, a slot's scope was inserted into the enclosing scope as if the slot element had tabindex=0.

A slot element itself is NOT focusable even if it has a tabindex. That does not change. A slot element is not a focusable by definition because it does not participate in the composed tree.

My preference is that we should honor the tabindex value of a slot element so that users can control the position of a slot's scope in the enclosing scope.

[Update]
I'm assuming that x-foo element itself, as well as x-bar, does not join the focus navigation here. See #126 for details.

[TakayoshiKochi]

Note that in the above example, if you put tabindex attribute in <x-bar>, x-bar itself becomes
focusable, and focus stops at x-bar, then the navigation gets inside x-bar. The delegatesFocus
flag controls the behavior, whether the focus navigation slips through the element or not.
I feel like it is natural to turn it on by default for a shadow host, and can be turned of if requested, as some component may want to take focus as a whole.

[TakayoshiKochi]

I support the idea of honoring <slot>'s tabIndex in the bottom of #375 (comment) .

[TakayoshiKochi]

@rniwa in #375 (comment) 's composed tree example, as <my-nameinput> doesn't have tabindex, I guess #search is visited first, then dive inside <my-nameinput>, because in that scope there are only <my-nameinput> and <input> and even we implicitly treat <my-nameinput>'s scope order as tabindex=0.

So even if you were just a web author using the third-party <contact-card> component, you have to be aware that there are separate tabindex scopes, one in <contact-card> and one in the main document.
If it's <contact-card>, it can be imaginable that the element is probably a custom element with shadow DOM, but in the case when it is a <div> with a shadow DOM, it will be hard to distinguish scopes at looking at the main document source alone?

Let me think more...

[hayatoito]

I agree that introducing scope for a slot is surprising for component users in some cases.

In fact, that's exactly the reason I could not take this approach in the past in Blink: This approach would break tabindex semantics for <details>/<summary> elements because <details>/<summary> is using Shadow DOM in Blink.

However, I think pros is much bigger than cons.

The cons happens in the limited case, I think, if the all of the following conditions are met:

• A shadow host is not a custom element
• A shadow host's child does not use a slot attribute, and it is assigned to the default slot

In other cases, developers can be aware that that "This tabindex is used in assigned slot's scope, rather than the current component tree's scope", I think.

Having said that, I still think that pros is much bigger than cons. If there is a way to avoid this cons somehow, it would be nice.

[TakayoshiKochi]

Just for reference, the discussion about focus and tab order for <details>/<symmary> is here:
https://bugs.webkit.org/show_bug.cgi?id=92050

[rniwa]

Perhaps what you need is a new attribute on slot element like focusScope that decides whether to define a new scope or not.

[hayatoito]

I think this is a blocking issue for v1. @TakayoshiKochi is working on having a formal definition in #381, I think.