Re: [webcomponents]: Shadow DOM + CSS = <3 Meeting Summary

On Tue, Jun 25, 2013 at 2:03 AM, Simon Pieters <> wrote:
> On Tue, 25 Jun 2013 01:01:44 +0200, Tab Atkins Jr. <>
> wrote:
>> On Mon, Jun 24, 2013 at 3:18 PM, Dimitri Glazkov <>
>> wrote:
>>> :host(div.who-mourns-for-morn) { ... } /*
>>>   matches a div with class "who-mourns-for-morn" anywhere in the outer
>>> trees,
>>>   up to and including the document tree */
>>> :host(<any-compound-selector>) /*
>>>   matches an element that matches <any-compound-selector> anywhere in the
>>>   outer trees (relative to this shadow tree), up to and including the
>>> document
>>>   tree. */
>>> Please note that only a compound selector
>>> ( is allowed in the
>>> host's parens.
>> Not quite.  These match the host element, *if* the provided selector
>> matches something on the fully composed ancestor list, starting from
>> the host and going up to the document root.  It lets you filter based
>> on outside context, not actually select something outside your
>> context.
>> Note: the reason we went for a compound selector here is that the
>> fully-composed ancestor list may include details of the shadow tree of
>> other components (for example, if your component is used *in* the
>> shadow tree of another component).  Being able to get *some*
>> information from that context is useful (it lets the outer component
>> signal to your component in useful ways), but we don't want to allow
>> you to depend on brittle and normally-hidden details of the inner
>> shadow tree of other components.  A single compound selector seems
>> like a good compromise.
>> (Oh, and now that I think about it, it should be a
>> <compound-selector-list>.)
> So it can contain commas...

Yes.  Note that this is the :host() pseudo-class, and will stay
functional.  (Just making sure you're not accidentally conflating it
with ::content, down below.)

>>> 4) Artist Formerly Known as ::distributed, Now Less Lispy
>>> We also killed the parens around ::distributed and renamed to
>>> ::content. See tabatkins@' clever twit about that
>>> ( Looking for
>>> allergic reactions to this particular pome.
>> This was done for two major reasons.
>> 1. Parens are annoying.  We like to avoid them when possible,
>> particularly when we run the risk of getting nested parens (imagine
>> mixing ::content() with ::region()...)
>> 2. Parens prevent us from interacting with any of the ideas for future
>> CSS rule nesting, where inner rules can extend the selector of the
>> outer rule.  We need the contents of the inner tree stuff to be at the
>> "top-level" of the selector for any of these to work right.
>> So, where previously you would select all the <li> elements that got
>> distributed to <content class='foo' select="li, p"> by doing something
>> like:
>> .foo::distributed(li) {...}
>> Now you just do:
>> .foo::content li {...}
>> This is meant to be a general idiom - pseudo-elements mean you've
>> switched to another tree.  Previously, all of our pseudo-elements were
>> leaf nodes anyway, so it was hard to detect exactly what it was doing,
>> but now that we have pseudos with complex structure inside of them
>> (::content, ::region, more?), we needed to settle on some pattern for
>> addressing the stuff inside of them, and this seems like the shortest,
>> clearest, most future-compatible way to do it.
> There's also ::cue().
> I don't understand how this idiom is supposed to work when you have a list
> of selectors as argument. Consider:
> video::cue(b, i) { background:lime }
> If it's changed to
> video::cue b, i { background:lime }
> then that looks like there are two selectors, "video::cue b" and "i".

Just use the existing CSS tools for indicating choice within a selector:

video::cue :matches(b, i) {...}


Received on Tuesday, 25 June 2013 17:31:16 UTC