In-place style definitions (not inline styles!). Inspired by tailwind but more vanilla.

[T3sT3ro]

Popularity of tailwind shows, that it's desirable to define styles in-place with component declarations. Personally I am a proponent of css styling solutions like Open Props. What do you think about a proposal like this:

Before

After

export component TodoList({ todos, addTodo }: Props) { <div class="container"> <h2>{'Todo List'}</h2> <ul> for (const todo of todos) { <li>{todo.text}</li> } </ul> if (todos.length > 0) { <p>{todos.length} {"items"}</p> } <Button onClick={addTodo} label={"Add Todo"} /> </div> <style> .container { text-align: center; font-family: "Arial", sans-serif; } ul * + * { margin-top: var(--size-1); } </style> }

export component TodoList({ todos, addTodo }: Props) { <div css={ /* single top level vanilla CSS */ text-align: center; font-family: "Arial", sans-serif; min-width: var(--size-2); }> <h2>{'Todo List'}</h2> <ul css={ /* regular vanilla CSS selectors + nesting */ & * + * { margin-top: var(--size-1); } }> for (const todo of todos) { <li>{todo.text}</li> } </ul> if (todos.length > 0) { <p>{todos.length} {"items"}</p> } <Button onClick={addTodo} label={"Add Todo"} /> </div> }

observations:

• Those are not inline classes
• It's vanilla CSS inside those brackets. It supports selectors, nesting etc. It uses default css parser with nothing extra. No new syntax to learn.
• No need to come up with names for arbitrary, single use classes generated automatically. Generated names could be human readable, based on component name and path into the element or something (no mangled mess).
• Thanks to vanilla CSS it doesn't have limitations like tailwind, where you are constrained by the framework. Media queries, container queries, custom properties can be defined in place, no need to wait when the framework will add support for it.
• Could be collapsed in the editor if needed. Reads well because style is collocated with the component, so there is no need to jump up and down in the file or have two editors open.
• An alternative to tailwind -> use native css in place instead of learning new framework. Would encourage css-first style systems (where style is defined in css variables) like Open Props.
• Can help with "locally scoped custom properties" (see also Kevin Powell's video and original idea post by Lea Verous). Intellisense would look for parent in the component tree instead of trying to parse the CSS. Basically:

  /* this is vanilla CSS btw, no new syntax, nothing fancy */
  parent {
    --_icon-color: var(--icon-color, red); /* global default with fallback */
    
    & svg {
      fill: var(--_icon_color); /* uses default */
    }
    
    & .special {
      --icon-color: var(--color-secondary, green); /* local override with fallback */
    }
  }

• The code in css={...} is proper CSS. Just a plain, embedded language, from the POV of parser.
• Top level selectors can be flat or in block css={ font-weight: 800; } or css={ &{ font-weight: 800;} }. Useful if wanting to, for example, define hover styles/psudo elements like

   css={ 
      & {...} 
      &:hover {...}
   }

• Could allow full intellisense, actions like going to declaration of local property, suggesting local properties etc. When the style is directly in the tree it should be easier to infer this than analyzing single css <style> tag.
• Could compile down to CSS with nesting. If someone wanted BEM it could be easy to add that too.
• Improves DX: in case of merges/splits/refactors, when you copy the component you copy the styles with it. You don't need to move a part of component and a part of tag separately.
• Ultimately it would just assemble the parts into a CSS. The idea is that whatever you have in <style></style> tag right now you could CTRL+C, CTRL+V piece by piece into the appropriate components' css={} blocks and vice-versa: merge those again into single css file (module class names, which in first case are redundant and in second are auto-generated by compiler).

[XCanG]

Template literal share common problem of not having syntax highlighting, autocomplete suggestions or more serious: applying on different states. Something like :hover, :focus, ... or even ::before, ::after. If it add any kind if inline syntax, then need to think of this problem in advance, otherwise you wont really use it and it will only be a burden.

[michaelheide]

The idea is great, everything is in place i get the pros.

But the cons are way bigger in my opinion. At the end why bloating a framework from the beginning with have style opinionated stuff, if you could just you class="" thats all what we want.
You can go with tailwind or any other CSS-Tooling like PandaCSS and so on.

It makes the framework more agnostic to everyone, no need to learn a new syntax, no need to maintain anything.
But at the end i get the point you wanna go with it.

[T3sT3ro]

I updated the example to clear up the confusion. Pay no attention to the tagged template literal (previously css=css`...` ), it was just a placeholder to show that it's pure CSS in those braces. No new syntax, works with vanilla CSS. The & {} I added is vanilla CSS used in nesting. Tools like TreeSitter support embedding languages in others, I don't know what kind of parser is used in here, but it should be possible to have that as well.

I would say it's as unopinionated as it gets, because it's just pure css but moved up and spliced from a single <style> block into separate css={} blocks.