[Shadow]: Focus navigation in distributed content

[tomalec]

The current Shadow DOM spec at Focus navigation does not specify how shadow tree nodes align to distributed ones, it only defines where entire tree is inserted. It's also not clearly stated to which tree (document tree or composed tree) sequential focus navigation should apply in general.
It says

If a node doesn’t participate in the composed tree, the node must be skipped from the navigation order..
therefore I assume that it applies

Therefore, I assume it should be applied to composed.

If it is applied to composed then it should be possible to place real light DOM nodes in between shadow tree nodes, and according to the order of shadow tree.

So for the case:

document tree
|-shadow host
  |-A focusable

shadow tree
|-1 focusable
|-2
  |-A insertion point
|-3 focusable

which gives

composed tree
|-shadow host
  |-1 focusable
  |-2
    |-A focusable
  |-3 focusable

The navigation order should be 1 A 3

And for more complicated case:

document tree
|-shadow host
  |-A focusable
  |-B focusable

shadow tree
|-1 focusable
|-2
  |-B insertion point
|-3
  |-A insertion point
|-4 focusable

which gives

composed tree
|-shadow host
  |-1 focusable
  |-2
    |-B focusable
  |-3
    |-A focusable
  |-4 focusable

The navigation order should be 1 B A 3, and not A B as if it would be for document tree.

Did I get the spec right?

Anyways I would say that it deserves detailed spec. And I would vote for such solution, as otherwise I do not see how Custom Element developer could use distributed content without breaking accessibility.

[tomalec]

Here is jsfiddle with test case, however it seems, that Chrome implementation (1 4 B A) does match with my interpretation, and I'm not sure whether it's Chromium bug, or the way it should be.

[hayatoito]

Thank you for the questions. You might want to see the relevant discussions:

• https://bugs.webkit.org/show_bug.cgi?id=92050
• https://www.w3.org/Bugs/Public/show_bug.cgi?id=18415

Therefore, I assume it should be applied to composed.

No. Unless otherwise mentioned, node trees are implied. I think the spec is clear because it uses a term of "shadow tree" or "parent tree".

The current behavior is intentional one.
I had to give up a composed tree based navigation due to the problems I mentioned in the discussions.

[tomalec]

Thanks for links.

I thought, if it says " the navigation order sequence for a given shadow tree A ", it defines the order of entire tree A in parent tree B, not the order of child nodes of shadow tree (1,2,3,4 incl. insertion points) in parent shadow tree A.

BTW, links to WHATWG discussion on tabscope is not working, but from what I have found it didn't get into spec.

So if I understood that correctly there is no way to achieve order:
shadow node 1 -> content -> shadow node 2 neither by shadow tree/custom element author nor by the user in document tree.

I believe, such order would be relevant for the huge set of custom elements.

[hayatoito]

Thanks.
Yeah, I agree the current wording needs to be improved. Maybe, it would be nice to have a concrete example in the spec, using a concrete example tree of tees. Adding more examples has been in my TODO-list.

AFAIK, there is no way to achieve such a composed-tree based navigation order. tabscope is still in the air. I would like to resolve this issue somehow because a composed-tree based navigation order is natural from the user's perspective. I don't want to give it up, however I hasn't spent much time on this issue so far.

[TakayoshiKochi]

Here's a similar issue filed for Chromium:
https://code.google.com/p/chromium/issues/detail?id=459858

Current TAB focus navigation is based on tree-of-trees based traversing and
there is no way to your shadow node 1 -> content -> shadow node 2 work
even with tabindex (or further the new 'tabstop' I'm working on).

Re-defining the focus navigation order of shadow DOM in terms of composed tree
would be one solution to this, but then it breaks

focusing behavior, which is also a valid case of using shadow DOM.

[tomalec]

I would be happy to help somehow.

Concrete example will be definitely useful.

Regarding wording, I'd like to make sure, I get current spec correctly

From discussions you mentioned I understood, that distributed content, from document tree perspective, are child nodes of shadow host, so its navigation order sequence will be added after navigation order sequence of shadow tree nodes.

Do I get it right that it's after not before, because of "2. in place of the HOST", and if I make HOST focusable, should shadow tree child nodes be inserted into sequence just after HOST node, and before distributed document tree child nodes, and not after HOST child nodes. In other words: does "1. immediately after HOST, if HOST is focusable;" applies for shadow tree A child nodes as well, but not for insertion point, means

1. "immediately after HOST node, if HOST is focusable;" not
2. "immediately after HOST subtree (from document tree perspective), if HOST is focusable;"?

[tomalec]

@TakayoshiKochi I understand that redefining in terms of composed tree without tabscope makes it impossible to use tabindexin document tree, but could you point how does it break focusing?

[hayatoito]

I'm afraid that I don't understand you questions fully.
The distribution itself doesn't have any effect on focus navigation, as long as the node participates in the composed tree (whose root node is a document).

You might want to see a concrete example in Layout Test in Blink, which I've written, until I add a concrete example to the spec. I hope that would help you to understand the spec's intention.

https://chromium.googlesource.com/chromium/blink/+/master/LayoutTests/fast/dom/shadow/focus-navigation.html

[hayatoito]

This example might not be a good example because it uses multiple shadow roots, which you can ignore.

[tomalec]

Thanks for example, it explains a lot.

Please disregard my previous question, I just wasn't sure if "HOST" refers to a tree or a node, but specs clearly says "shadow host is an element..".

I've made a test for my case: https://gist.github.com/tomalec/3129b2474ff496c75fdc, and line 52 is the one that confused me most in the begging. So the fact that:

• shadow tree nodes are handled according to the same rules,
• content distribution nodes are non-focusable so they does not change focus navigation, distributed nodes are part of document tree scope.

What was not so intuitive, that <content> tag affects focus navigation, as only distributed nodes take part, but cannot change the order as regular DOM.

BTW, you have a typo in Blink test sahdow -> shadow, travese -> traverse

[hayatoito]

Thanks.

What was not so intuitive, that tag affects focus navigation, as only distributed nodes take part, but cannot change the order as regular DOM.

Totally agreed. I really hope we have a nice solution for this issue in the future.
AFAIK, we don't have any good idea how 'tabindex' attribute of such a distributed node should be used if we are trying to adapt composed tree based traversing.

I guess if Web Components becomes widely used, there would be much attentions for this issue.
Anyway, the discussion happeing here would be a good pointer to explain the current non-ideal situation. Thank you for filing this GitHub issue.

BTW, you have a typo in Blink test sahdow -> shadow, travese -> traverse

Thanks. :)

[TakayoshiKochi]

@tomalec I meant the original bug in https://bugs.webkit.org/show_bug.cgi?id=92050 , <summary>
with tabindex doesn't work as intended (which is already fixed).

If <details> is implemented using user-agent shadow DOM and distributes <summary> inside
its shadow, and if <summary>'s navigation order is reordered due to distribution, you may get
unexpected ordering.

Note on Oct. 7, 2015: edited broken markups

[hayatoito]

Let me close this issue. This topic is now being discussed in #375.