Suggestion: Modify createVar to return --name instead of var(--name).

[zeakd]

Hi team! I'm Big fan of vanilla-extract, and my team’s been using it extensively in our projects. We use CSS variables a lot to create flexible styling interfaces that make it easy to customize components beyond the props.

For example:

import { Card, variables } from 'my-card'

<Card ... title='Title' style={{ [variables.titleColor]: 'Tomato' }}></Card>

Ideally, we’d like to declare these CSS variables with createVar without worrying about conflicts, but right now createVar returns a var() wrapped string:

const titleColorVar = createVar();
// var(--_7hp1ul0)

While there are workarounds (like declaring variables manually, using utilities with functionSerializer, or calling the private getVarName), I’m wondering if createVar really needs to wrap the output in var(). Without this wrapping, we could simplify things and skip some extra abstraction.

Here’s how it might look without the var() wrapping:

export const titleColorVar = createVar(); // return '--_7hp1ul0' instead of var(--_7hp1ul0)

export const cardRoot = style({
  [titleColorVar]: 'blue',
});

export const cardTitle = style({
  color: fallbackVar(titleColorVar, 'black'),
});

Pros

1. Direct usage within style() without needing a vars property:

   export const accentVar = createVar();
   
   export const blue = style({
     // vars: {
     //   [accentVar]: 'blue'
     // }
     [accentVar]: 'blue'
   });

2. Cleaner inline styles without needing assignInlineVars:

   import { accentVar } from './my.css.ts';
   
   // <div style={assignInlineVars({ [accentVar]: 'blue' })}>...</div>
   <div style={{ [accentVar]: 'blue' }}>...</div>

Cons

1. For cases where assignVar() is needed, or where variables are used directly as values within style(), we’d need to manually wrap them with var().

   const colorVar = createVar();
   
   const cardTitle = style({
     color: assignVar(colorVar),
   });
   
   // Or, handle variables in `style` to wrap with `var(--variable)` if needed inside renderCss
   const cardTitle = style({
     color: colorVar,
   });

Curious to hear your thoughts on this approach. I think it could streamline some workflows and make vanilla-extract even easier to use. Thanks for taking the time to consider it!

[askoufis]

It seems like you might be after the assignInlineVars function from @vanilla-extract/dynamic.

[askoufis]

Oh my bad, missed the bit where you mentioned that API 🤦

[zeakd]

Thanks for the response! The idea here is to explore a way where assignInlineVars wouldn't be necessary at all for cases like these. If createVar returned the variable name directly, it would allow us to handle inline styling with plain CSS variables, keeping the API even lighter. Curious to know your thoughts on this approach!

[kasper573]

I think this looks like a much more composable api design than the existing one. But it would be a pretty hefty breaking change.

[6mint]

While I would welcome to get rid of the vars property in the style rules, having to wrap the variable with var() each time I'm using it as a value sounds slightly worse. At least because using a variable tends to happen more often then assigning to it.

But it would be nice if getVarName would move to a "shared" (or similar) import — importing something from "/private" makes my worry that my project might break between minor VE updates because it gives me to understand that I'm dealing with internals here.

An alternative approach might be to allow properties starting with "var(--" in style rules and handing the wrapper removal internally within the style() function and other parts of the api that handle StyleRule. This would make the vars property obsolete.
( assignVar() would still be needed which I didn't experience as a significant pain point so far in the last 2 years of VE).

This way we could just write

export const accentVar = createVar();

export const blue = style({
  [accentVar]: 'blue',
  color: accentVar
});

The tradeoff here would be that a style rule would deviate more from correct CSS Syntax. So far, exceptions have only been made for simple pseudo selectors as far as I know.