Why doesn't this nested selector work "& > * ~ *"

[joseDaKing]

When I try this it will give me an error that is saying

const spaceX = style({
    selectors: {
        "& > * ~ *": {
            marginLeft: `calc(${value} * calc(1 - ${fallbackVar(spaceXReverseVar, "0")}))`,
            marginRight: `calc(${value} * ${fallbackVar(spaceXReverseVar, "0")})`,
        }
    } 
})

Error: Invalid selector: & > :not([hidden]) ~ :not([hidden])

Style selectors must target the '&' character (along with any modifiers), e.g. `${parent} &` or `${parent} &:hover`.

This is to ensure that each style block only affects the styling of a single class.

I don't want to have global styles, I want it refer to its own className, Is it possible to do it

[joseDaKing]

I don't think this library supports it

[askoufis]

@GideonMax There is currently no way to turn off this behaviour. The main reason for this is that we believe it results in more maintainable styles.

By enforcing that a style can only ever target the element it is applied to, you can better reason about how styles affect your components, both as you're developing them and after coming back to them the future.

This can sometimes result in more verbose styles, but the tradeoff is an overall reduction in styling complexity.

[black7375]

Like StyleX, this is an intentional rule.
Of course, sometimes I want to use & > * too.
However, I believe that in most cases the current rules are a better way to go.

[carvallegro]

@askoufis I understand where you're coming from and I can see why you want to encourage certain practices but I feel like enforcing in the code without any opt-out strategy results in a not so good developer experience.

Your philosophy makes sense but I feel like hard rules should only be implemented in a library unless it creates an actual technical issue. Even more so, this decision is not clearly communicated in the documentation so there is a fair chance that developers would only realize it once they started adopting Vanilla Extract.

Educating developers on best practices and ensuring that a clean codebase is created makes sense but it would not remove anything from the library to be able opt-out to follow a different approaches that is equally valid but happens to be incompatible with what Vanilla Extract chose to use.

[askoufis]

@carvallegro

I feel like enforcing in the code without any opt-out strategy results in a not so good developer experience.

There is an "opt-out strategy": the globalStyle API.

I think we might have different ideas of what a good developer experience is, in this particular case. To me, "good developer experience" in this case doesn't necessarily mean "enabling the developer to easily do exactly what they want", but rather "guiding the developer towards better practices via API constraints".

It would not remove anything from the library to be able opt-out to follow a different approaches that is equally valid but happens to be incompatible with what Vanilla Extract chose to use.

While global styles are "valid", in the sense that you can use them to achieve a goal, the constraints in Vanilla Extract are there because we fundamentally believe that scoped styles that only target a single element are better than global styles.

Compromising on this constraint would mean allowing consumers to more easily write styles in a worse way. This seems like a worse developer experience to me (at least as far as the goals of Vanilla Extract are concerned).

This decision is not clearly communicated in the documentation

For reference, this is documented here, but I agree that it's not presented in an upfront way like it is in the StyleX docs. There is crossover between StyleX's opinions and Vanilla Extract's opinions, so perhaps a "Core principles" page would be useful.

[carvallegro]

Thanks for the response @askoufis, it does seem like we have different views on the matter but it's great that we can discuss it!

I am not convinced by your arguments but I can definitely appreciate Vanilla Extract being consistent in its approach. I do think that the globalStyle API is more of a workaround than an opt-out strategy but we will be using this moving forward.

Vanilla Extract is a great library and we are using it for our internal Design System here at Jane. I do hope that you will reconsider the approach in the future and offer a real opt-out strategy that would allow developers to willingly ignore the approach and have more freedom with selectors. Until then, globalStyle it is!