- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 6 May 2015 07:18:51 -0700
- 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:39 UTC