- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 25 Jun 2013 10:30:29 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>, Hayato Ito <hayato@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, Jonas Sicking <jonas@sicking.cc>, William Chen <wchen@mozilla.com>, Blake Kaplan <mrbkap@mozilla.com>, Daniel Buchner <daniel@mozilla.com>, Dominic Cooney <dominicc@chromium.org>, Takashi Sakamoto <tasak@google.com>
On Tue, Jun 25, 2013 at 2:03 AM, Simon Pieters <simonp@opera.com> wrote: > On Tue, 25 Jun 2013 01:01:44 +0200, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: >> On Mon, Jun 24, 2013 at 3:18 PM, Dimitri Glazkov <dglazkov@google.com> >> 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 >>> (http://dev.w3.org/csswg/selectors4/#compound) 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 >>> (https://twitter.com/tabatkins/status/348190487003410433). 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) {...} ~TJ
Received on Tuesday, 25 June 2013 17:31:16 UTC