- From: Simon Pieters <simonp@opera.com>
- Date: Tue, 25 Jun 2013 11:03:27 +0200
- To: "Dimitri Glazkov" <dglazkov@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: 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, 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... >> 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". -- Simon Pieters Opera Software
Received on Tuesday, 25 June 2013 09:01:59 UTC