This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15529 - [Shadow]: ShadowHost's tabindex attriblue
Summary: [Shadow]: ShadowHost's tabindex attriblue
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 14978
  Show dependency treegraph
 
Reported: 2012-01-12 03:25 UTC by Hayato Ito
Modified: 2012-01-13 21:19 UTC (History)
0 users

See Also:


Attachments

Description Hayato Ito 2012-01-12 03:25:13 UTC
How should we treat ShadowHost's tabindex attribute?

Let me explain by the following example:
  <input id='A' tabindex='2'/>
    <shadowhost tabindex='1'>
      - shadowRoot
         <input id='B'/>
         <input id='C'/>
    </shadowhost>
  <input id='D' tabindex='3' />

In this case, in which order should we traverse in sequential focus navigation?

1).  B -> C -> A -> D (ShadowHost acts like a iframe element, becoming a scope of sequential focus navigation.)
2).  A -> D -> B -> C (ShadowHost's tabindex is not honored, every elements are 'flattened'.)
3).  Anything else?

The spec seems that say 2) is the desired behavior. Note that current WebKit's implementations acts like 1).
Comment 1 Dimitri Glazkov 2012-01-12 04:26:48 UTC
I thought I already spec'd this out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#focus-navigation

Can you verify and make sure there aren't holes?
Comment 2 Hayato Ito 2012-01-12 05:58:13 UTC
(In reply to comment #1)
> I thought I already spec'd this out:
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#focus-navigation
> 
> Can you verify and make sure there aren't holes?

Thank you. I've read it and understand that the spec clearly mentioned the navigation order. Awesome.
Let me ask two questions to make sure that my understanding is correct. My questions come from the different behavior between ShadowHost and iframe.

1). If shadow host is focusable, like:

  <input id='A' tabindex='2'/>
  <shadowhost id='B', tabindex='1' (focusable) >
    - shadowRoot
         <input id='C'/>
         <content>
         <input id='D' tabindex='1'/>
    <input id='E' tabindex='2' />
  </shadowhost>
  <input id='F' tabindex='3' />

The spec says we should navigate this tree in the following order:

Document navigation order: B > A > F
Shadow DOM navigation order: D > E > C
In total:  B > D > E > C > A > F

Let me confirm that a shadow host itself (= B) participates in focus navigation, right?


2). If shadow host is not focusable like:

  <input id='A' tabindex='2'/>
  <shadowhost id='B', tabindex='-1' (non-focusable) >
    - shadowRoot
         <input id='C'/>
         <content>
         <input id='D' tabindex='1'/>
    <input id='E' tabindex='2' />
  </shadowhost>
  <input id='F' tabindex='3' />


Document navigation order: A > F > B (assuming B's tabindex=0 (Does 'auto' means tabindex=0?))
Shadow DOM navigation order: D > E > C
In total:  A > F > D > E > C

Let me confirm that we have no way to skip entire shadow DOM from focus navigation, right?
Comment 3 Dimitri Glazkov 2012-01-12 17:01:28 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I thought I already spec'd this out:
> > http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#focus-navigation
> > 
> > Can you verify and make sure there aren't holes?
> 
> Thank you. I've read it and understand that the spec clearly mentioned the
> navigation order. Awesome.
> Let me ask two questions to make sure that my understanding is correct. My
> questions come from the different behavior between ShadowHost and iframe.
> 
> 1). If shadow host is focusable, like:
> 
>   <input id='A' tabindex='2'/>
>   <shadowhost id='B', tabindex='1' (focusable) >
>     - shadowRoot
>          <input id='C'/>
>          <content>
>          <input id='D' tabindex='1'/>
>     <input id='E' tabindex='2' />
>   </shadowhost>
>   <input id='F' tabindex='3' />



> 
> The spec says we should navigate this tree in the following order:
> 
> Document navigation order: B > A > F
> Shadow DOM navigation order: D > E > C
> In total:  B > D > E > C > A > F
> 
> Let me confirm that a shadow host itself (= B) participates in focus
> navigation, right?
> 
> 
> 2). If shadow host is not focusable like:
> 
>   <input id='A' tabindex='2'/>
>   <shadowhost id='B', tabindex='-1' (non-focusable) >
>     - shadowRoot
>          <input id='C'/>
>          <content>
>          <input id='D' tabindex='1'/>
>     <input id='E' tabindex='2' />
>   </shadowhost>
>   <input id='F' tabindex='3' />
> 
> 
> Document navigation order: A > F > B (assuming B's tabindex=0 (Does 'auto'
> means tabindex=0?))

It means the absence of index.

> Shadow DOM navigation order: D > E > C
> In total:  A > F > D > E > C
> 
> Let me confirm that we have no way to skip entire shadow DOM from focus
> navigation, right?

Yup. You've got it.
Comment 4 Dimitri Glazkov 2012-01-13 21:19:25 UTC
Please reopen if this needs more work.