Re: [css-scoping] Was shadow host intended to be more feature-less than "featureless"?

On Tuesday 2015-04-07 17:48 -0700, Tab Atkins Jr. wrote:
> On Tue, Apr 7, 2015 at 4:59 PM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Tuesday 2015-04-07 16:45 -0700, Tab Atkins Jr. wrote:
> >> Ugh, hit send a little too early.
> >>
> >> On Tue, Apr 7, 2015 at 4:43 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> >> > Correct, it *should* match those pseudos.  The whole "featureless"
> >> > concept exists *solely* to prevent a component author from
> >> > *accidentally* matching the host element due to the component *user*
> >> > doing something to it.  The component author should be able to write a
> >> > rule against a `.foo` class without risking accidentally targeting the
> >> > host element just because the component user, unaware that .foo is
> >> > being used inside the component, puts a class=foo on the host element
> >> > for their own unrelated styling purposes.
> >>
> >> Note, though, that the Blink implementation currently *does* exclude
> >> everything - it literally returns false immediately if the selector
> >> has anything else in it.  This was semi-intentional when implemented,
> >> but I defined things the way I did on purpose, and Blink's current
> >> behavior is a bug.
> >
> > But Blink's behavior seems like a much clearer mental model for
> > authors:  that only :host, :host(), and :host-context() can match
> > outside of the component.
> >
> > It seems odd to me that when the host element is a p element
> > currently in the :active state, that the following selectors would
> > match it (as part of a larger selector with combinators):
> >   :host
> >   :host(p)
> >   :host(:hover)
> >   :active
> > but that the following:
> >   p
> > would not match.
> 
> Hm, for some reason I'd forgotten about :host().  I suppose
> :host(:hover) isn't any more difficult than :host:hover.  I guess I'd
> be okay with redefining featureless elements more strictly to make
> them not match *any* selectors unless otherwise specified?
> 
> > And if :active on the host element works, why shouldn't authors
> > expect it to also work on ancestors of the host element (which
> > doesn't work, since those ancestors aren't considered at all)?
> 
> Ancestors aren't part of the shadow tree at all; I'm not sure why
> authors would expect them to be matched in the first place, as that
> would violate the entire point of the shadow tree.  The host element
> is the only one that's kinda ambiguous about whether a component
> should be able to match it or not.

I agree with that.

I was just saying that if authors learn that:

  :active .class-in-shadow-tree

works when :active matches the host element, they may well be
confused that it doesn't work when :active matches an ancestor of
the host element, just like they'll also be confused when they learn
that this same thing doesn't apply to:

  .class-on-host-element .class-in-shadow-tree


I'm happy with the proposal of making featureless elements not match
any selectors unless otherwise specified.  (My understanding is that
that matches both Chrome's implementation and the in-progress Gecko
implementation.)

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)