- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 27 Apr 2015 14:14:10 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "www-style@w3.org" <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>, WebApps WG <public-webapps@w3.org>
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