On Tue, 25 Jun 2013 01:01:44 +0200, Tab Atkins Jr. <[email protected]>
wrote:
On Mon, Jun 24, 2013 at 3:18 PM, Dimitri Glazkov <[email protected]>
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
