Recipe base has higher priority than variants

[gabro]

Is this expected?

E.g. given

const reset = style({
  background: "transparent",
});

export const buttonRecipe = recipe({
  base: [reset, sprinkles({ paddingX: "4" })],
  variants: {
    kind: {
      primary: sprinkles({ color: "white", background: "primary60" }),
      secondary: sprinkles({ color: "black", background: "neutral50" }),
    },
  },
});

The resulting component has background: transparent.

I would've expected the variants to have higher precedence.

[markdalgleish]

This is because your sprinkles have a lower specificity than the newly-created reset style.

The easiest fix is to avoid Sprinkles here entirely, but that's obviously not ideal. Personally, I'd recommend moving the transparent background into its own kind variant so that you avoid applying conflicting styles.

[gabro]

Aha, that explains it, thanks!
I must say I was a bit confused since the documentation examples explicitly feature a reset style in one of the example, but I suppose now that it works because it doesn't use sprinkles.

Any recommended approach to css reset? Should I just avoid style properties that I know will be set by the recipe variants?

[markdalgleish]

Yep, it's a good idea to avoid setting the same property simultaneously across the base styles and different sets of variants.

[gabro]

Ok, sounds good, thanks 🙏

[okonet]

I just ran into a similar problem where I have a Box component that has reset defined in the Box.css.ts like this:

import { style } from '@vanilla-extract/css';

export const reset = style(
  {
    padding: 0,
    margin: 0,
    border: 0,
    boxSizing: 'border-box', // Ensure that padding is included in width
    minWidth: 0, // ensure the Box can shrink below its minimum content size when used as a flex item
    verticalAlign: 'baseline',
    WebkitTapHighlightColor: 'transparent',
  },
);

and then I'm using it with sprinkles like this <Box padding="medium">...</Box> but the Box's own reset styles are always higher than sprinkles in specificity:

Essentially I'm doing very similar to https://github.com/seek-oss/braid-design-system/blob/dbdeed0e2c992921505fa49994db94d1af333ce1/lib/css/atoms/atoms.ts but it doesn't seem to work as expected.

[okonet]

It looks like the "only" way to solve this is to define reset styles before sprinkles i.e. in the sprinkles.css.ts before the sprinkles themselves. IMO this is very counter-intuitive and it would be great to have some level of control or even a heuristic that sprinkles should always be created at the latest point. Not sure it's possible but just saying...

[mattcompiles]

While I admit the whole CSS ordering stuff is a problem and can be confusing. Unfortunately it's out of our control. Vanilla-extract doesn't do any CSS bundling, it just creates CSS files. Your bundler of choice then does the rest, and most bundlers just work off of import order.

In Braid we create our reset first, then sprinkles then custom styles.

[okonet]

@mattcompiles ah okay it makes sense now. When you say “we create first” what do you mean by that? How do you ensure that reset is the first?

[mattcompiles]

We ensure it is imported first. We actually ask the consumers of the design system to import it before all their own styles as well as part of the setup docs.

You can see them here: https://github.com/seek-oss/braid-design-system

It's not ideal, but it's also not a huge problem.

[mwood23]

This just bit me too. Since it's outside of the control of the library itself, perhaps a lint rule could help for these edge cases? I'm not sure of a way to enforce this in a way that every bundler would respect.

[bwyx]

or maybe introduce a new API like styleReset or configurable layer of specificity level that could have lower priority than sprinkles itself?

[Shawkry]

I am very confused about how to set the backgroundColor when disabled, because if I set it this way, the disabled state won't take effect, since it seems that the status in the recipe has a higher priority.Even if disabled is included as a variant in the recipe, it still seems that the status has slightly higher priority. I am quite confused about how the priority is determined in this context.

CSS:

export const disabled = style({
  backgroundColor: '#CCCCCC',
  cursor: 'not-allowed',
});
const statusVars = {
  normal: {
    backgroundColor: '#87CEFA',
  },
  success: {
    backgroundColor: '#90EE90',
  },
  warning: {
    backgroundColor: '#F0E68C',
  },
  error: {
    backgroundColor: '#C10000',
  },
};
export const button = recipe({
  base: buttonBaseStyle,
  variants: {
    size: sizeVars,
    type: typeVars,
    status: statusVars,
  },
});

TSX

import * as css from './style/index.css';
const Button: React.FC<IButtonProps> = (props) => {
  const { disabled, status, label } = props;
  const mergeCls = classNames(
    css.button({
      status,
    }),
    {[css.disabled]: disabled},
  );
  return (
    <button
      className={mergeCls}
      disabled={disabled}
    >
      {label}
    </button>
  );
};