Re: :host pseudo-class

On Mon, May 4, 2015 at 9:52 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron <dbaron@dbaron.org> wrote:
>> On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren 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.
>>
>> 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.
>
> My understanding is that the question here isn't what is being
> matched, but rather what syntax to use for the selector. I.e. in both
> cases the thing that the selector is matching is the DocumentFragment
> which is the root of the shadow DOM.

As Anne said, no, the thing matched is the actual host element.  But
otherwise, yeah, we're just debating the syntax of how to select that
(while obeying the constraints I outlined in my first post to this
thread).

> If implementing :host is easier than ::host, then it seems like the
> implementation could always convert the pseudo-element into a
> pseudo-class at parse time. That should make the implementation the
> same other than in the parser. Though maybe the concern here is about
> parser complexity?

It's not about parser complexity. (dbaron did use that as an argument
against ::host, but I'm not making that argument; Blink's parser has
no problem with it.)  It's about hitting the (admittedly complex)
constraints sanely within the existing Selectors model.

~TJ

Received on Tuesday, 5 May 2015 18:43:05 UTC