W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: :host pseudo-class

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 6 May 2015 07:18:51 -0700
Message-ID: <CAAWBYDCdZ6WP1r74YjjSYbgwUOStCtR2ZXgqsptqoqnySrNCsA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Elliott Sprehn <esprehn@chromium.org>, "www-style@w3.org" <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>, WebApps WG <public-webapps@w3.org>
On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> It's certainly no weirder, imo, than having a pseudo-element that
>> doesn't actually live in any element's pseudo-tree, but instead just
>> lives in the normal DOM, but can only be selected by using a
>> pseudo-element selector with no LHS.  Pseudo-elements are fucked,
>> unfortunately, but we have to live with their quirks, and those quirks
>> make them really bad for this particular case.
>
> Why?

As was said before, pseudo-elements have to be attached to a real
element.  Pseudo-element selectors have a built-in combinator; they're
actually complex selectors all by themselves.  (This isn't properly
reflected in Selectors right now; I haven't made the edits to the data
model that need to happen to make pseudo-elements work properly.)

But the host element isn't attached to any of the elements in its
shadow tree; it's a *parent* of all of them.  If we ignored this and
let it attach to an element, which one?  There's no single top-most
element to privilege.  If we attach to *all* of them, then we get the
bizarre result that "#foo::host > #foo" might actually select
something.  Having lots of elements share the same pseudo-element is
also unprecedented currently.

Pseudo-elements also, because they're complex selectors, aren't usable
everywhere that other selectors are.  If you have a context that only
accepts simple or compound selectors (as a filter, for instance),
pseudo-elements aren't available.

So if we use :host, we have to invent a new concept to make it work
(featureless). If we use ::host, we have to invent a new concept to
make it work (new ways for pseudo-elements to exist and be targeted).
I think the latter is weirder than the former.

> And again, from the perspective of the shadow tree, the host element
> is not part of its normal DOM. The shadow tree is its normal DOM. This
> is the same as ::-webkit-range-thumb. From the perspective of the
> light DOM, that element is not part of its normal DOM. But it is part
> of the composed DOM.

And again, it depends on what level of authority you're talking about.
As far as the outer page is concerned, the <input> element is empty,
and ::webkit-range-thumb is a fictitious pseudo-element created solely
by the platform.  There's no real DOM underlying it, because the
shadow dom is fully sealed, so anything inside of it is dead.

>From the platform's perspective, sure, there's a real element under
there.  And the platform does get special powers that the page might
not have.  But the fact that <input> is implemented with shadow DOM is
an undetectable implementation detail at the moment.

~TJ
Received on Wednesday, 6 May 2015 14:19:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC