Embarrassing strawman API proposal that hopefully gets the point across

Button.js

// This is _not_ supposed to be a real API. It's only intended to describe what
// I'm looking for. It's almost intentionally awful.

export const buttonHook = new OverrideHook({
  properties: ['margin'],
});

export default function Button(props) {
  return (
    <button
      {...props}
      type="button"
      className={classNames(
        props.className,
        buttonClassName,
        buttonHook.className
      )}
    />
  );
}

InlineForm.js

import { buttonHook } from './Button';

// This is _not_ supposed to be a real API. It's only intended to describe what
// I'm looking for. It's almost intentionally awful.

const formClassName = makeClass({
  border: '1 px solid grey',

  [s`> ${buttonHook}`]: buttonHook({
    margin: '0 1rem',
  }),
});

export default function InlineForm(props) {
  return (
    <form
      {...props}
      className={classNames(props.className, formClassName)}
    />
  );
}

// The idea is that you can do:
const form = (
  <InlineForm>
    <EmailInput />
    <PasswordInput />
    <LoginButton />
  </InlineForm>
);

// Where <LoginButton> renders a <Button>.

Toolbar.js

import { buttonHook } from './Button';

// This is _not_ supposed to be a real API. It's only intended to describe what
// I'm looking for. It's almost intentionally awful.

const toolbarClassName = makeClass({
  border: '1 px solid black',

  [s`> ${buttonHook}`]: buttonHook({
    margin: '0 0.5rem',
    // If you try to set font-family or something here, throw.
  }),
});

export default function Toolbar(props) {
  return (
    <div
      {...props}
      className={classNames(props.className, toolbarClassName)}
    />
  );
}

@threepointone

Something like this came up in a different Twitter thread https://twitter.com/jimmy_jia/status/759605418389868544 😃

It works, and it's got the right semantics of where styles are defined.

I have to think about this more. It feels a lot like re-inventing CSS selectors using React context – like, written this way, it lets you write the equivalent of a .btn-toolbar .btn selector.

You could write something like a .btn-toolbar > .btn selector by mapping and cloning children and injecting e.g. buttonStyle as a prop instead of using context.

And you could use something like mapping children or like @vjeux's approach to get stuff equivalent to :nth-child selectors.

I don't know. It feels like these concepts should be more unified. Doing something like using context for .parent .child, cloning with props for .parent > .child feels less than ideal. They're similar enough concepts that IMO the code should look similar too.

I can see how glamor can avoid the potential precedence issues with e.g. CSS modules, though. That's pretty cool.

Yup – so the question is something like... this lets you write .parent .child, but you'd need select() or something from @vjeux's https://gist.github.com/vjeux/8e27dd06c64dc566bfee705e1b19cb18 to handle e.g. .parent > :last-child.

To me, that feels like a bit of a disadvantage; .parent .child, .parent > .child, and .parent > .child:last-child feel like similar enough concepts that the syntax should also look similar.

Trying to move discussion to styled-components/spec#5.