Re: [webcomponents] [Shadow] Section 2.4 - CSS inherit by default? (#314)

I really wish I hadn't been sick, and forced to skip that f2f, because I could have cleared up a lot of confusion. :/

We should be inheriting by default.  It's what *all* shadow-root-ish things in the platform do today, it's what all components have done since we initially implemented them.  It's required for variables to work, at the bare minimum.

If you want to shut down inheritance entirely, you have the `all: revert` declaration (which forces the element to ignore all author-level styling, styling it as if only the UA and user stylesheets existed).  The opposite way, forcing inheritance, is done by `all: unset`, which causes the element to either take its inherited or initial value, as appropriate.

For further styling, beyond what's reasonable to do with variables, we have [the @apply rule](https://tabatkins.github.io/specs/css-apply-rule/), which the WG approved work on.  It needs some clarifications (hammered out in the meeting) to avoid circularity, and then it needs to be moved into the WG repository, but it's otherwise done.  It allows passing an entire ruleset via the variables mechanism, so the component author can allow arbitrary styling of a shadow-tree element without exposing a ton of variables.

There's one hole remaining in this functionality - the ability to style a shadow-tree element based on states, like :hover or :active.  Handling this with `@apply` as written gives the same problems as before - the component author has to define a ton of variables for all the combinations of states that they want to expose.  This then calls for [CSS Rule Nesting](https://tabatkins.github.io/specs/css-nesting/), which I recently revised (and which is *insanely popular* among webdevs).

Between Variables, and the combination of `@apply` and Nesting, all styling needs are taken care of, as far as I can tell.  There's no need to invent a new pseudo-element functionality.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/314#issuecomment-143828813

Received on Monday, 28 September 2015 18:11:43 UTC