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

On Tue, Apr 7, 2015 at 1:12 PM, L. David Baron <dbaron@dbaron.org> wrote:
> http://dev.w3.org/csswg/selectors-4/#featureless says:
>   # Individual featureless elements may define additional
>   # restrictions on what kinds of selectors can match them.
>   #
>   # EXAMPLE 3
>   # For example, the host element in a shadow tree is featureless,
>   # and can’t be matched by any pseudo-class except for :host and
>   # :host-context().)
>
> http://dev.w3.org/csswg/css-scoping-1/#host-element-in-tree also
> says in a note:
>   # So, to allow this situation but prevent accidental styling, the
>   # host element appears but is completely featureless and
>   # unselectable except through :host.
>
> This makes it appear that it was clearly intended that the host
> element never match selectors other than :host, :host(), and
> :host-context().

No, that's just fluff text that's saying things a bit stronger than
intended.  (I wrote that text.)  The fluff text is sometimes
simplified from the actual spec, because the actual spec is
complicated and full of qualifications.  Read the actual spec parts
for the details of what the host element matches.

> However, I don't see anything in the spec that makes this be the
> case.  http://dev.w3.org/csswg/css-scoping-1/#host-element-in-tree
> defines the host element to be featureless, which means that it
> doesn't match tag selectors, class selectors, id selectors, or
> attribute selectors.  However, it still seems like the shadow host
> would match pseudo-classes like :hover, and also negated
> pseudo-classes like :not(:hover).

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.

For the most part, only the "feature selectors" are controllable by
the component user.  Most pseudo-classes can't be manipulated by the
component user in any significant way; those that can, like
:nth-child(), aren't generally used "bare", so it's pretty safe for
them to still match the host element.  Either it's useful for them to
match, like :hover, or they'll usually be paired with some other
selectors that'll exclude the host element, like `.foo >
:nth-child(3)`, so it's not worth the effort of trying to specifically
exclude those pseudo-classes as well.

> It seems like the spec intends to make the shadow host not
> "accidentally" match selectors like :hover or :not(:hover) so that
> such selectors don't accidentally match outside of the shadow tree.
> However, it's not clear to me what mechanism the spec intends to
> make that happen.
>
> (It also seems like the "featureless" concept is perhaps more
> complicated than needed and doesn't quite solve the problem it was
> intended to solve, since it doesn't actually solve the problem with
> :not() accidentally matching outside of the shadow tree.)

Could you provide more detail here?  For example, `:not(div)` won't
match a featureless element, per spec.  As far as I can tell, it
solves the problem I describe above.

~TJ

Received on Tuesday, 7 April 2015 23:44:24 UTC