Re: [webcomponents] Update Section 6.2 Focus Navigation to reflect TPAC discussion (#375)

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* of each scope. 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 other slot.
- The following is the behavior what I am expecting, using more comprehensive tree of trees:

e.g.

document tree:
```html
  <input id=i0 tabindex=0></input>
  <x-foo>
    <input id=i2 slot=s1 tabindex=2></input>
    <input id=i1 slot=s1 tabindex=1></input>
  </x-foo>
```

`<x-foo>`'s shadow tree:
```html
  <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:
```html
  <input id=k0 tabindex=0></input>
  <slot id=s2 name=s2></slot>
  <input id=k1 tabindex=1></input>
```

The sequential focus navigation of 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, *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 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.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/375#issuecomment-178989178