Styled-jsx: >>: unprefixed descendant selector / shadow piercing

[rauchg]

It'd be interesting to skip prefixing if the user uses >>:

export default () => (
  <div>
    <div class="my-component">
      <MyComponent /> { /* this component has a <span> child */ }
    </div>
    <style jsx>{`
       .my-component >> span {
         color: red
       }
    `}</style>
  </div>
)

Not sure if >> is in conflict with any existing or future CSS specs, but I like this a lot. styled-jsx effectively turns the CSS model upside down, making the dangerous aspects of it "opt-in", through, in this case the extra >>

[rauchg]

TIL: https://drafts.csswg.org/css-scoping/#deep-combinator

[rauchg]

Curious why it's >>> and not >>? cc @TakayoshiKochi @hayatoito @annevk

[luisrudge]

why would you want to not autoprefix stuff?

[rauchg]

@luisrudge I normally don't. My preferred pattern is to pass _props_ to make changes _explicit_ on both sides.

Passing props establishes a _contract_, whereas this introduces external mutations that are unexpected by the component.

But there are edge cases and scenarios where people might want to override a 3rd party codebase, for example.

[luisrudge]

oh, sorry.. I thought this was for stopping autoprefix for unsuportted properties.. 😊 Forget I was here :D

[treshugart]

@rauchg I'm fairly certain the shadow piercing combinator is deprecated?

[rauchg]

@treshugart not according to:

https://github.com/w3c/webcomponents/issues/78#issuecomment-248560978
https://github.com/w3c/webcomponents/issues/78#issuecomment-248563163
https://github.com/w3c/webcomponents/issues/78#issuecomment-264403496

I'm still curious why it's >>> and not >> ¯_(ツ)_/¯

[treshugart]

@rauchg Ahh yep, I remember reading the thread a couple months ago. At that time the discussion ended around "not useful for closed trees". Still lots of contention. And yeah, I never understood the extra > either.

[rauchg]

Just based on the initial feedback to styled-jsx, I have a strong instinct that it's good to have it as a occasional escape hatch. So even if it ends up being deprecated, it might be cool to support it

[annevk]

I don't know, but I'm pretty sure this feature lacks agreement.

[hayatoito]

">>" is an alias for "" (space; descendant combinator), though >> is not widely supported by UAs, as of now, I think.
See https://drafts.csswg.org/selectors-4/#descendant-combinators for the spec.

In summary:

• >: child
• >>: descendant
• >>>: shadow-crossing descendant

[pemrouz]

@rauchg to clarify, that thread is only about >>> in JS btw (querySelector, querySelectorAll). It's deprecated for styling in CSS. @dglazkov put together the best writeup here. I agree it's the wrong approach to theming, but also that it should be available via JS.

Still, I'm +1 for keeping it as an escape hatch here and seeing how people use it :)

[rauchg]

Got it.

1. It's a bit weird that it'd work on one side (JS) and not the other (CSS)
2. I think it's a nice escape-hatch because it's so gross-looking and explicit (specially with three >)

So, still interested in retaining it!

[rauchg]

Thanks @annevk @hayatoito @pemrouz for weighing in

[TakayoshiKochi]

As already mentioned, >>> is for use only for JS (querySelector), not for CSS styling, and is still contentious. If you are interested, please follow the discussion at https://github.com/w3c/webcomponents/issues/78.

On the other hand >> could be used for styling. As of now, only Safari 10 implements >> (caniuse).

[giuseppeg]

@rauchg

My preferred pattern is to pass props to make changes explicit on both sides.

This could be also done with CSS Custom Properties already.

But there are edge cases and scenarios where people might want to override a 3rd party codebase, for example.

I think that a named <slot> for user styles could solve this issue POF: http://codepen.io/giuseppegurgone/pen/dOKWpV?editors=0010 (we'd need to add prefixing).

Both soultions are very future proof and the latter could be an HOC or something.

[ericclemmons]

It's weird for auto-prefixing to _not_ be a default (I'd <3 to see a compelling argument), but is adding props to style acceptable?

export default () => (
  <div>
    <div class="my-component">
      <MyComponent /> { /* this component has a <span> child */ }
    </div>
    <style no-autoprefix jsx>{`
       .my-component > span {
         color: red
       }
    `}</style>
  </div>
)

Go all out with props:

{/* All classes get normalize.css-equivalent applied wo0t! */}
<style normalize jsx>

Alright, I'm done bikeshedding. :wave:

[rauchg]

I definitely thought about it. Notice #5

[thysultan]

@rauchg namespace prefix? can't you do this with :host-context(.my-component span) {}

[giuseppeg]

@thysultan you can't reach to the "shadow dom" from the outside with :host-context.
It works like this:

const MyComponent = () => (
  <div>
    <span>hello</span> {/* this is red */}
    <style jsx>{`
      span { color: red; }
      :host-context(.my-component) span { color: green; }
    `}</style>
  </div>
)

const App = () => (
  <div class="my-component">
    <MyComponent /> {/* the span now will be green */}
  </div>
)

@ericclemmons I think that react has a whitelist of valid html attributes and warns when it finds invalid ones, therefore those should be stripped out at transpilation time. Also this pattern looks a bit like passing N arguments to a function... it could get nasty, maybe a better way to pass options would be to set the jsx attribute value to an object like:

const options = {
  autoprefix: false
}

<style jsx={options}></style>

[thysultan]

@rauchg :host-context(.my-component) span { color: green; } will generate .my-component .user {color: green;} without a namespace. What did you have in mind for .my-component >> span to yield?

[giuseppeg]

@thysultan the difference is subtle.

@rauchg is describing a way to tweak component styles from the outside with >>>
while :host-context is internal to the component:

:host-context(.my-component) span { color: green; } means when MyComponent is rendered inside of an element with class my-component then span will get color: green – this behavior is defined in the target component (MyComponent).

[thysultan]

@giuseppeg thanks i get it now, similar to @root or a @at-root block in scss but for a single specific selector. @rauchg could this work.

<<< .my-component span {}

// or
<< .my-component span {}

[jozanza]

I'm very interested in this feature!

For clarity, are we thinking the styles defined with the >>> escape hatch would cross all descendants or just the immediate ones? Also, other styles defined inside the same <style jsx> without the escape hatch, would be scoped as normal still, correct?

[rauchg]

We ended up implemented this with :global, inspired by css modules: https://github.com/zeit/styled-jsx#global-selectors

Hope you like it!