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

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>.)

> 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.

> 5) Custom Pseudo-elements Part-y
>
> To avoid using "x-" prefix and unable to find anything more elegant,
> we agreed to use a new ::part(name) syntax for custom pseudo-elements,
> also renaming the respective attribute. In other words, instead of
> <div pseudo="x-rawr"></div>, which is reachable from outside of the
> shadow tree as host::x-rawr, we turned this into:
>
> <style> #host::part(rawr) { border: 1px red solid; } </style>
> <div id="host"></div>
> <script>
>    var root = document.querySelector('#host').createShadowRoot();
>    var div = root.appendChild(document.createElement('div'));
>    div.part = 'rawr'; // I haz red border nao.
> </script>

Note as well the possibility raised in the meeting, that while we
can't explain the current shadow-like pseudo-elements in this form, it
may be worthwhile to *duplicate* them into this form.

That is, for pseudo-elements like input::placeholder, it may be
worthwhile to also allow referring to them with
input::part(placeholder), as if the internal shadow of the <input>
actually did have a <span part=placeholder> somewhere in it.

~TJ

Received on Monday, 24 June 2013 23:02:31 UTC