Re: :host pseudo-class

On Sat, Apr 25, 2015 at 9:32 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> I don't understand why :host is a pseudo-class rather than a
> pseudo-element. My mental model of a pseudo-class is that it allows
> you to match an element based on a boolean internal slot of that
> element. :host is not that since e.g. * does not match :host as I
> understand it. That seems super weird. Why not just use ::host?
>
> Copying WebApps since this affects everyone caring about Shadow DOM.

Pseudo-elements are things that aren't DOM elements, but are created
by Selectors for the purpose of CSS to act like elements.

The host element is a real DOM element.  It just has special selection
behavior from inside its own shadow root, for practical reasons: there
are good use-cases for being able to style your host, but also a lot
for *not* doing so, and so mixing the host into the normal set of
elements leads to a large risk of accidentally selecting the host.
This is particularly true for things like class selectors; since the
*user* of the component is the one that controls what classes/etc are
set on the host element, it's very plausible that a class used inside
the shadow root for internal purposes could accidentally collide with
one used by the outer page for something completely different, and
cause unintentional styling issues.

Making the host element present in the shadow tree, but featureless
save for the :host and :host-context() pseudo-classes, was the
compromise that satisfies all of the use-cases adequately.

It's possible we could change how we define the concept of
"pseudo-element" so that it can sometimes refer to real elements that
just aren't ordinarily accessible, but I'm not sure that's necessary
or desirable at the moment.

On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron <dbaron@dbaron.org> wrote:
> We haven't really used (in the sense of shipping across browsers)
> pseudo-elements before for things that are both tree-like (i.e., not
> ::first-letter, ::first-line, or ::selection) and not leaves of the
> tree.  (Gecko doesn't implement any pseudo-elements that can have
> other selectors to their right.  I'm not sure if other engines
> have.)
>
> I'd be a little worried about ease of implementation, and doing so
> without disabling a bunch of selector-related optimizations that
> we'd rather have.
>
> At some point we probably do want to have this sort of
> pseudo-element, but it's certainly adding an additional dependency
> on to this spec.

The ::shadow and ::content pseudo-elements are this way (tree-like,
and not leaves).  We implement them in Blink currently, at least to
some extent.  (Not sure if it's just selector tricks, or if we do it
"properly" so that, for example, inheritance works.)

On Mon, Apr 27, 2015 at 1:06 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> Thanks, that example has another confusing bit, ::content. As far as I
> can tell ::content is not actually an element that ends up in the
> tree. It would make more sense for that to be a named-combinator of
> sorts. (And given ::content allowing selectors on the right hand, it's
> now yet more unclear why :host is not ::host.)

It's a (pseudo-)element in the tree, it's just required to not
generate a box.  Having ::content (and ::shadow) be pseudo-elements
lets you do a few useful things: you can use other combinators (child
*or* descendant, depending on what you need) and you can set inherited
properties to cascade down to all the children (especially useful for,
for example, setting 'color' of direct text node children, which can
appear in a shadow root or in a <content> with no select='', and can't
be targeted by a selector otherwise).  I did originally use
combinators for this, but they're less useful for the reasons just
listed.

(This was explicitly discussed in a telcon, when I noted that
sometimes you want to select the "top-level" things in a shadow tree
or distribution list, and sometimes all the things.  I had proposed
two versions of each combinator, or an argument to a named combinator
(like /shadow >/ versus /shadow >>/), but someone else (I think it was
fantasai?) suggested using a pseudo-element instead, and it turned out
to be a pretty good suggestion.)

~TJ

Received on Monday, 27 April 2015 21:15:04 UTC