Add an option that enables targeting child elements

[henrify]

The constaint that each style defining code block can target only one element might be a good idea for design system components and greenfield projects, but it is a total show-stopper when trying to migrate an older real world app that contains combination of reusable components, one off pages, and half a decade of organic evolution.

Without that constraint we could do pretty much mechanical or even automated codemod translation from CSS modules + SASS to vanilla-extract. With that constaint the migration requires manual and significant refactoring of the entire code base and becomes economically unfeasible.

[futbotism]

Tend to agree, this library looks amazing and the amount of effort and thought that went into it really shows. but for me without the ability to target child elements the lib is unfortunately unusable.

targetting child elements is something which made scss far superior to css im not sure why it wouldn't be allowed here. It would be great to have some documentation or an exmaple of a best pratice explaining the technical reasons why we shouldn't target child selectors.

Once again thanks for this increible library

[askoufis]

You can sort of target child elements, but you have to define a separate child style and explicitly apply it where needed. Alternatively, you can globally target child nodes with globalStyle, but that comes with other constraints:

export const parent = style({...});
export const child = style({
  selectors: {
    [`${parent} &`]: {...}
  }
});

globalStyle(`${parent} a`, {...});

The reason this constraint exists is because we believe it makes it easier to understand how your styles affect your markup, since a style can only over affect a single element. This helps both when reading your markup in the devtools, or in your actual code. Ultimately we think it leads to more maintainable styles in the long run.

Sure, it might be more verbose and time consuming having to write styles for both the parent and the child, and it will likely have an effect how you structure your markup/components as well. In the long run though, we think this tradeoff is worth it, particularly for larger apps/component libraries/design systems.

Vanilla Extract wasn't designed with the explicit goal of making it easy to automatically migrate from other styling solutions. We think that the constraints it has help you write more maintainable styles, so of course coming from a styling solution that has less constraints is going to involve some manual effort. This could result in a large, potentially unfeasible, cost to migrate, at least manually. There is likely room for some amount of automatic migration, however we don't provide any official tools for that.

[futbotism]

ok well fair enough if that's the design choice. Its a shame because this library is a perfect fit save for that one feature :(