Re: :host pseudo-class

On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 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.

Sure it is.  <input type=range> has no children, and the shadow tree
is sealed, so the fact that a shadow tree even exists is hidden from
DOM.  As far as CSS is capable of discerning, there is no thumb
element, so the pseudo-element makes sense.

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

I don't understand what distinction you're trying to draw here.  Can
you elaborate?

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

That's just a naming-collision thing.  We can come up with a different
name for either "has a shadow tree" or "is the host element of the
current shadow tree"; it's just that right now, the latter has claimed
the name ":host".

I certainly don't want to create both a pseudo-class and
pseudo-element with the same name if I can help it (or at least, not
ones that refer to similar things); the distinction between
pseudo-classes and pseudo-elements in most author's minds is already
tenuous.  (Definitely not helped by the legacy :before/etc syntax.)

~TJ

Received on Friday, 1 May 2015 00:08:39 UTC