Bug 92050 – Focus navigation of <summary> element should not be ruled by Shadow DOM spec.

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: DOM

[Hayato Ito]

In current WebKit inplementation,  a <summary> element is distributed into an insertion point of shadow DOM subtree inside of <details> element.
Therefore, it follows a rule defined in the Shadow DOM spec: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#focus-navigation.

That's not a desired behavior. Focus navigation for <summary> elements should follow the usual focus navigation rule of outer document, not Shadow DOM spec.
That means that tabindex attribute of <summary> element should be used for an outer document, not for an inside of Shadow DOM subtree.

[Dimitri Glazkov (Google)]

I am curious why this is necessary. Should we change the spec instead?

[Hayato Ito]

Let me make the issue clear at first. Suppose the following elements are given:

A1 <input tabindex=1>
A2 <input tabindex=2>
A3 <input tabindex=3>
A4 <input tabindex=4>
A5 <input tabindex=5>
B2 <input tabindex=2>
<details>detail
    <summary tabindex=2>summary</summary>
</details>


If we focus 'A1' at first, focus navigation by pressing Tab-key should be in the following order:
   A1-> A2 -> B2-> summary-> A3-> A4-> A5

The current implementation does not follow this order because a focus scope of <summary> element is not the one of the outer document. <summary> element is distributed into an insertion point in the current implementation.

(In reply to comment #1)
> I am curious why this is necessary. Should we change the spec instead?

I am not sure how we can change the spec. Maybe we could mention like:

[You should assume that <details> element is a shadow host and a <summary> element is distributed into an insertion point of shadow DOM subtree.]

If we mention that in the spec, the issue will disappear.

Let me think further.

[Dimitri Glazkov (Google)]

Something is odd here. It seems that any distributed element should indeed act like the <summary> element in your example.

[Hayato Ito]

Okay. I am wondering that my understanding of the spec is correct or not.

From the spec (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#focus-navigation):
> The navigation order within the shadow DOM subtrees must be determined using the as-rendered structure and is called shadow DOM navigation order.

From the view of focus navigation, my current understanding of the spec is that distributed nodes are rather parts of shadow dom subtree, not parts of the outer document tree since focus navigation should use the as-rendered structure.

Is my understanding correct?

(In reply to comment #3)
> Something is odd here. It seems that any distributed element should indeed act like the <summary> element in your example.

[Hayato Ito]

A: Distributed nodes join the focus navigation of the shadow DOM subtree.
B: Distributed nodes join the focus navigation of outer document tree.

Until now, I have been thought that A is natural than B.
But I've found that a 'tabindex' attribute of distributed nodes does not make much sense in A.
Component users can not predict how a tabindex attribute of a distributed node is *effective* in the shadow DOM subtree.

[Dimitri Glazkov (Google)]

(In reply to comment #5)
> A: Distributed nodes join the focus navigation of the shadow DOM subtree.
> B: Distributed nodes join the focus navigation of outer document tree.
> 
> Until now, I have been thought that A is natural than B.
> But I've found that a 'tabindex' attribute of distributed nodes does not make much sense in A.
> Component users can not predict how a tabindex attribute of a distributed node is *effective* in the shadow DOM subtree.

Right, I now think B is more natural. WDYT?

[Hayato Ito]

(In reply to comment #6)
> (In reply to comment #5)
> > A: Distributed nodes join the focus navigation of the shadow DOM subtree.
> > B: Distributed nodes join the focus navigation of outer document tree.
> > 
> > Until now, I have been thought that A is natural than B.
> > But I've found that a 'tabindex' attribute of distributed nodes does not make much sense in A.
> > Component users can not predict how a tabindex attribute of a distributed node is *effective* in the shadow DOM subtree.
> 
> Right, I now think B is more natural. WDYT?

I am not still convinced that B is more natural than A even if I've found 'tabindex' attribute of distributed nodes is *useless* in case of A.
There are a lot of use cases where A provides more natural navigation than B does.

We might want to discourage users from setting 'tabindex' attributes for distributed nodes.
Users can still control focus navigation of distributed nodes by setting tabindex attribute of its host elmenets and achieve the *similar* results.

[Dimitri Glazkov (Google)]

(In reply to comment #7)

> We might want to discourage users from setting 'tabindex' attributes for distributed nodes.

We can't do that :) In the context of a complex, you may not even know which node is distributed at any given moment.

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18415 to grapple with this issue at the spec level.

Not sure what to do with this specific case in the meantime.

[Hayato Ito]

(In reply to comment #8)
> (In reply to comment #7)
> 
> > We might want to discourage users from setting 'tabindex' attributes for distributed nodes.
> 
> We can't do that :) In the context of a complex, you may not even know which node is distributed at any given moment.
> 
> I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18415 to grapple with this issue at the spec level.

Thank you for filing the bug. The issue should be discussed at the spec level.

> 
> Not sure what to do with this specific case in the meantime.

Neither I am. Let me leave this bug open to track the issue for details/summary elements.

[Dominic Cooney]

I note that the linked spec bug is fixed.

[Ryosuke Niwa]

Moving this under the bug 72352 for simplicity.

[Ryosuke Niwa]

No longer relevant.