Re: [css-selector] :focus and shadow host

Hi!

Thanks for trying to understand the confusing doc :)

I'll try to make things as clear as possible.

On Fri, Mar 20, 2015 at 3:20 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> I'm a little confused by the Doc.  It, and this email, attempt to
> define tabStop as "basically HTML spec's 'tabindex focus flag'".  But
> it's definitely not - your "State 2" makes this clear, because the
> HTML spec sets the 'tabindex focus flag' when tabindex is negative.
>
>
Hmm, when tabindex is negative (-1),
I thought tab navigation skips the element,
thus "tabindex focus flag" is false then.
Where in the HTML spec sets the flag?

(I may miss something obvious)


> It appears that tabStop is actually "this element is in the
> 'sequential navigation navigation order'".  Is this right?  I'll
> assume that it is for the rest of this email.
>
>
Yes.



> In that case, I *guess* this makes sense?  The tabindex puts it in the
> sequential navigation order, but the tabStop property indicates that
> it's not *really* in the order?
>
>
Right, not in the order when tabStop = false.


I'm not sure how this explains the behavior of <input>, though.  From
> what I understand of the Doc, you would set tabStop=true on <custom-a>
> and the like, to make them show up in the sequential navigation order
> even when tabindex isn't set at all.  But you're saying that to
> trigger this case, you need to set tabStop=false, and require a
> non-negative tabindex value.  <input> doesn't need to be auto-focused,
> though.
>
>
Hmm, originaly tabStop meant to be for *shadow host*s, when authors
want to put tab order of a shadow host via tabindex but doesn't want
the host itself takes focus (delegates focus to its inner elements in its
shadow tree).

Without using tabStop property at all, if you don't specify tabindex on a
shadow host,
tab navigation behavior works as most authors expect for e.g.
<custom-input>, I believe.

Once you put non-negative tabindex on a shadow host, the host itself
becomes focusable,
which may not be the desired behavior, for e.g. <custom-input>.
tabStop=false works for this case.

(I don't understand why "auto-focus" is relevant here)

Basically I'm pretty confused about this whole thing and how tabindex
> and tabStop are supposed to interact.
>
> (Tangent: I'm also confused about how tabStop is supposed to be
> writable, when tabindex apparently implicitly sets it as well.  Do you
> have to listen for tabindex mutations and continually reset tabStop to
> the value you want?  Or does it remember when it's been "manually
> set", and stop listening to tabindex mutations?  Or something else?
> Neither of these options have good ergonomics. :/ )
>
>
That's a good point, to keep the compatibility of existing "tabindex",
some complexity seems inevitable, though there may be better ideas.


> ~TJ
>



-- 
Takayoshi Kochi