Add nested selectors

[joseDaKing]

Nested selectors would allow for more composability, readability, and smaller selector.

const styles = style({
  selectors: {
    "&:not([data-disabled])" {
      backgroundColor: themeVars.primary50,
        selectors: {
          "&[data-state='checked']": {
            backgroundColor: themeVars.primary100,
            ":hover: {
              backgroundColor: themeVars.primary200 
            },
            ":focus: {
              backgroundColor: themeVars.primary300
            },
            ":active: {
              backgroundColor: themeVars.primary400
            },
          }
        }
      }
    }
  }
});

[simontaisne]

Yes, that would really be useful!

[rostero1]

I'm revisiting Vanilla Extract and just ran into this. How do I solve this with the example above?

(I'm also using this within a a recipe variant)

[rostero1]

I wouldn't even mind targeting the following, but it's an invalid selector.

selectors: {
  "&[data-state='checked']:active": {

[roginfarrer]

It's not the most intuitive, but I've addressed these cases by changing my mental model for how to apply styles when there's multiple variants. I'm not 100% sure this ideal, but it worked for me.

Vanilla Extract doesn't work well when trying to apply a condition-based style, then to further override that condition-based style with another condition. That's typically what we use nesting for, to dig into a complex state of conditions.

What worked for me was to flatten the states, and use CSS variables to help avoiding specificity and cascade issues. So in your example, each state would be an "or", instead of "and".

// create a variable for our background color
const bgColor = createVar();

// This is our base class implements where the variables are used
const base = style({
  backgroundColor: bgColor
});

export const variants = styleVariants(
  {
	// use styleVariants to define our stateful variants
    notDisabled: {
      vars: {
        [bgColor]: themeVars.primary50
      }
    },
    notDisabledAndChecked: {
      vars: {
        [bgColor]: themeVars.primary100
      },
      ":hover": {
        vars: {
          [bgColor]: themeVars.primary200
        }
      },
      ":focus": {
        vars: {
          [bgColor]: themeVars.primary300
        }
      },
      ":active": {
        vars: {
          [bgColor]: themeVars.primary400
        }
      }
    }
  },
  // Compose with the base
  (variant) => [base, variant]
);

Now the complexity of the conditions is handled in the implementation:

getVariantClass(disabled, checked) {
  if (disabled) {
    return '';
  }

  return variants[checked ? 'notDisabledAndChecked' : 'notDisabled'];
}

Pros of this solution:

• Clearly organize the different presentational states of a component/element, which nesting can obfuscate
• Reduce possibility of cascade/specificity issues
• When using CSS vars, it works really well to separate the skeleton of a style rule (the "base" above), and its values, especially when dealing with pseudo elements, like ::after, ::before, or ::placeholder.

Cons of this solution:

• styleVariants only works to produce classes, it's not exactly like using attributes, as your original suggestion has
• Compartmentalizing the different states can mean producing more styles than with nesting and overriding, which attempts to minimize the number of styles produced
• Moves styling complexity to the implementation (we had to make a getVariantClass func)

I think if you wanted to continue using data-attributes, you could roll your own styleVariants function with globalStyle.

[rostero1]

Thanks for helping with this. I started looking into Griffel too, which allows for nested selectors, but isn't as widely adopted.