When a shadow host which is normally unfocusable (e.g. <div>), have 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. <input> with a shadow DOM, some tricky workarounds are needed
or at least exposing HTML "tab focusable flag" on an element[1].

This is not specified in the shadow DOM spec [2] 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[1].

[1] Tabindex Focus Navigation Explainer
https://docs.google.com/a/chromium.org/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit
[2] Shadow DOM
http://w3c.github.io/webcomponents/spec/shadow/