Re: :host pseudo-class

On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Pseudo-elements are things that aren't DOM elements, but are created
> by Selectors for the purpose of CSS to act like elements.

That's not true for e.g. ::-webkit-slider-thumb as I already indicated.


> 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.

My problem is not with the ability to address the host element, but by
addressing it through a pseudo-class, which has so far only been used
for matching elements in the tree that have a particular internal
slot.


> 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.

Well, it would for instance open up the possibility of using :host in
the light tree to match elements that are host elements.


> 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.

Actually, it is my understanding that it's not in the composed tree.
Similar to an element that is not inserted. And the composed tree is
the input to CSS, not the various trees it is made of. However, you
make a good point that you do want a box of sorts there to set color
and such and given that a pseudo-element makes sense.


> 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.

It's not entirely clear to me how ::shadow should cope with closed
shadow trees. E.g. I imagine you cannot use it to style <details> for
instance?


-- 
https://annevankesteren.nl/

Received on Thursday, 30 April 2015 09:28:15 UTC