Re: :host pseudo-class

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.

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?

/ Jonas

Received on Tuesday, 5 May 2015 04:53:40 UTC