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

On Thu, Mar 19, 2015 at 12:16 AM, Takayoshi Kochi (河内 隆仁)
<kochi@google.com> wrote:
> Hi,
>
> I've been working on making custom elements/shadow dom compatible with
> native elements, and currently working on focus stuff.
>
> The primary motivation for us is, to make a custom <input type="date"> with
> web components, for example.
>
> See the following example:
> http://jsbin.com/mupekazigo/1/edit
> (the background turns yellow when it gets focus)
>
> <input type="date"> is implemented in Chrome using shadow dom, and
> the actual editing element is within the shadow tree, but "input:focus"
> matches
> when its descendant element in the shadow tree is focused.
>
> We would like to make custom-date-input:focus also match without breaking
> existing components.
>
> What we'd like to propose is, that making :focus on shadow host match when
> its
> inner element gets focus, on a condition that the host's tabindex >= 0 and
> its
> tabStop (which is new [1], basically HTML spec's "tabindex focus flag[2]")
> is "false".
>
> Currently, :focus pseudo class on shadow host is defined not to be
> in the focused state even when its inner element is focused:
> http://dev.w3.org/csswg/selectors-4/#the-focus-pseudo
>
> (Note that :focus-within, :hover, and :active for shadow host works when
> its inner element gets its matching state.)
>
> Prior to [1] draft, there are only 2 states for any element:
>
> 1. tabindex >= 0 and tabStop = true
> 2. tabindex = -1 and tabStop = false
>
> but shadow host can be in the third state
>
> 3. tabindex >=0 and tabStop = false
>
> where tabbing focus navigation will obey the "tabindex" order but actual
> focus is delegated
> into its inner focusable element.
>
> The shadow-host:focus matching behavior only happens in the 3rd state.
>
> Of course, functionally speaking :focus-within can do what we want, but in
> that case
> <input type="date"> and <custom-date-input> are not interchangeable
> (:focus-within
> works for both, :focus works only for <input>).

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.

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.

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?

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.

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. :/ )

~TJ

Received on Thursday, 19 March 2015 18:21:45 UTC