Re: Shadow DOM Encapsulation

On Feb 7, 2014, at 10:32 AM, Tab Atkins Jr. wrote:

> Peter Linss wrote:
>> The only interesting thing here is that there's an implied > between all pseudo-elements and the rest of the selector, so:
>> p::first-line
>> is morally equivalent to:
>> p > ::first-line
>> That's the way Gecko at-least used to do it internally...
>> 
>> We did this back in '98 or so in Gecko when building form controls out of "anonymous" boxes and hidden dom nodes (for content and event handling), essentially the 16 year-old precursor to today's shadow-dom. The interesting "anonymous" boxes each had a pseudo-element name and you could simply style them with normal CSS selectors.
> 
> On further thought, this doesn't work at all, at least not without
> breaking the current model.  Let's take ::before as an example.
> 
> "p::before" selects the 'before' pseudo on the <p> element.  "p
> ::before" selects the 'before' pseudo on all descendants of <p>.
> 
> You said that in Gecko's old model, ::before is a hidden child of <p>,
> so that "p::before" is morally equivalent to "p > ::before" (taking
> "::before" as the tagname of the before pseudo, or something similar).
> Presumably the idea is that if there's no combinator between the
> ::before and its preceding selector, that implies a child combinator.
> 
> That means, though, that "p ::before" won't need any fixup, as it's
> got a combinator.  But that then has a different meaning than what CSS
> currently assigns it - it'll select the ::before pseudo of <p> *and*
> its descendants, rather than just the ::before pseudo of its
> descendants.
> 
> Either the model needs to *further* special-case the descendant
> combinator, or it changes the current meaning of selectors.
> 
> (Recall that I tried, probably two years ago, to get :: as a
> combinator so we could explain pseudo-elements better within the
> model. I ran into similar issues with the current syntax, and we
> weren't willing to break things for it.  It sucks.)

Please don't get hung up on this bit. There's nothing in my proposal of exposing component pieces as pseudo-elements that requires changes to the way current pseudo-elements are handled. This was more of an aside about an implementation detail from Gecko code once-upon-a-time. Gecko treated pseudo-elements as logical constructs within the parent, that's all I was getting at.