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]

@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!

[ymeine]

I would genuinely like to understand how this:

const css = {
    table: style({}),
};

globalStyle(`${css.table} td:first-child`, {
    borderTopLeftRadius: '0.25rem',
    borderBottomLeftRadius: '0.25rem',
});
globalStyle(`${css.table} td:last-child`, {
    borderTopRightRadius: '0.25rem',
    borderBottomRightRadius: '0.25rem',
});

can actually be considered a better practice and more maintainable than this:

const css = {
    table: style({
        selectors: {
            '& td:first-child': {
                borderTopLeftRadius: '0.25rem',
                borderBottomLeftRadius: '0.25rem',
            },
            '& td:last-child': {
                borderTopRightRadius: '0.25rem',
                borderBottomRightRadius: '0.25rem',
            },
        },
    }),
};

Especially that this is just an example with a reduced amount of code.

I thought the goal of Vanilla Extract was to bring two main things:

• type safety, based on TypeScript
• computational power, based on JavaScript platform

However, assuming than one style is better than another and trying to over assist developers who are too often wrongly considered as unable to distinguish good code from bad code is - in my opinion - degrading the value of such project a lot.

With years of experience, I've seen many projects where the idea was great, and the technical added value was tremendous. But too often library creators assumed that developers (the users of the library) would not be smart enough and they decided to restrict the API or capabilities of the library in some way to "protect" them. It made those libraries unusable in more advanced cases where developers knew what they were doing.

I understand that in the case of the feature discussed here the functionality is still available (globalStyle), but this can't be good DX all the time and some people, like in my case, will suffer from such decisions. Vanilla Extract does have the power to match CSS more closely though, and that would include being able to nest such selectors in style declarations. Not all features in development systems are good that's for sure, but I doubt that such nesting is really considered a bad thing in CSS or SCSS (even more since instead of dropping this feature, CSS finally adopted it from SCSS). Why would it be so bad in Vanilla Extract, which already does a great job in reducing mistakes thanks to type safety and the possibility to share definitions/variables way more easily?

The lack of this feature is honestly a reason why I would fork the project, but I can't, this is too much work: as I said, the technical added value here is huge and everything is there, but a person foreign to the project with very little time would take forever just to add that one thing. Without mentioning the burden of maintaining a fork, and potentially repeating the whole process for any project making use of Vanilla Extract (macaron for instance).

I'm sorry if that may sound a bit harsh, but the frustration to see such a unique, great and technically complex project becoming practically unusable (for me) because of an opinion that didn't take into account the diversity of kinds of projects and the differences in how people's brains work is of course really bumming me.

I hope the decision on this topic is not something set is stone. And after all, even though I emit my own opinion, I'm not the one who created the project and made the gift of open sourcing and maintaining it, which is honestly maybe the hardest part here: the owners/contributors have much more right to do arbitrary decisions. I just feel it's a shame to restrict the potential of the library on that particular point.

[radnan]

I think for your very specific example of table and cell it might seem like a good idea - but what if we start introducing more nuance here.

Like what if I want to hide the first column of my table using “display: none” but keep it present in the DOM. Now the second column should actually have the corner radius style - but table has no way of knowing when a cell is hidden or not. Similarly what if I want to hide the first row - now the second rows cells should have this corner radius.

Or maybe for a particular case the cell should not have a corner radius at all because we need to show another element underneath which is not a table row (maybe pagination controls).

At that point when you go to reset the radius on the cell itself you start hitting selector specificity issues because the table child selector has higher specificity. All of this and more are reasons why you want your styles to be scoped very deliberately.

Cause once you give devs this freedom they’re gonna come up with things that’ll give you nightmares lol. And then you end up with the same brittle issues as regular CSS - which is that you can’t manage it properly. You can’t know when a style is used for a particular component directly (you have to hunt down other places to figure that out). And most importantly you don’t know when to clean up something because you just don’t know how it’s going to effect something else just because they happen to have a hierarchical structure within the DOM.

[ymeine]

As your examples suggest: it depends.

In the cases you describe, it may be possible that applying classes to individual elements is more maintainable, or even required. And therefore it means that we need to create individual classes, and for that Vanilla Extract excels already.

But this is valid only if the use case changes, for instance in the way you describe. In the example I gave, it still makes more sense (at least to me) to use a descendant combinator based selector. And in that case, Vanilla Extract makes it less practical, or dare I say convoluted.

Also, it seems to me that a lot of people often assume that we control the pieces of code end to end; not only in Vanilla Extract, I’ve seen it in other projects as well. That is often not the case. Still in the context of the example here, using an hermetic 3rd party table component would prevent from being able to inject custom classes into cells in a clean way (in a non-clean way, almost everything is possible anyway).

Cause once you give devs this freedom they’re gonna come up with things that’ll give you nightmares lol. And then you end up with the same brittle issues as regular CSS - which is that you can’t manage it properly. You can’t know when a style is used for a particular component directly (you have to hunt down other places to figure that out). And most importantly you don’t know when to clean up something because you just don’t know how it’s going to effect something else just because they happen to have a hierarchical structure within the DOM.

I’m not sure I follow you on this whole paragraph. First of all, my CSS is co-located (even in the same file as the code thanks to macaron), so I don’t have to hunt down other places to understand what is happening. I never meant to apply the example I gave to the root of the DOM in some global styling context - and even if I did, how could anyone legitimately assume that I can’t understand and control what I did myself? For that matter, I guess people also often assume team work, in which case the decision parameters do change indeed. I’m not saying that when working in a team this feature (that we would like to have here) does not make sense, I’m just saying its use should be evaluated differently based on people’s own particularities.

To sum it up, when I do something in my code, I do know. And if something does not work, I do know how to investigate and fix it. And if I work in a team, I take extra care to discuss that with others, to document the code if needed (for future collaborators for instance), or to use a different technique if we assume it’s better for that particular case.

---

As a side note: I’ve started experimenting with writing a Vite plugin (that could be adapted to any other bundler since it’s just code transformation) to extract the global selectors that Vanilla Extract recognizes and deliberately rejects, and transform them into globalStyle calls. I realized it’s much more acceptable than going through the path of forking the repositories 😄

[ymeine]

Well, it turns out the Vite plugin is not that simple…

First of all, I wanted to make it work on a project which uses macaron, but the latter is actually completely circumventing the Vite modules transformation pipeline and reads the files directly on disk. For the kind of task I want to do, this means it becomes a nightmare and I don’t want to fight that much to hack that somewhat surprising design (is it due to Vite’s limitations?)

So then, since I had an implementation ready to be tested, I switched back to pure Vanilla Extract, and my plugin did work. However, this handles only the very simple cases, which are the ones I mostly use. During the implementation, I discovered that there are many edge cases.

So it’s feasible, but at a cost of:

• maintaining a plugin
• distributing it (publicly or privately) for use across projects
• be ready to deal with tricky edge cases

Looking for alternatives, I had a look at panda.

It has a decent DX regarding the integration in projects.

On the APIs side, it fixes the main issues:

• CSS rules don’t have to be in a different file (well, there’s an exception, see below)
• there’s no restrictions on how to structure them (so nesting any selector will work)

However it does have some pain points too:

• purely global CSS rules can’t be authored anywhere you want, they have to be in the panda configuration file. For the use case, it may be acceptable - I personally generally have those rules near my entry point anyways, so shifting them to the configuration file should not break my organization too much
• more problematic: it generates utility classes

The use of utility classes is another nightmare. This breaks semantics:

• people can’t use anymore class based CSS selectors to target elements (for customization, data scraping, etc.). However one may argue that using custom data attributes or similar technique would be a much better alternative, and here I agree
• however this still prevents proper customization of styling on the end user side: they can’t anymore modify the styles per type of element, they would modify only global stylistic traits. For that use case, CSS introduced a while ago CSS custom properties which I believe are a more robust solution here
• I can’t toggle a whole style block using the browser DevTools anymore (with the class toggling feature), since instead of one single class, multiple ones are being generated

CSS is not just about “making it work”, the structure of the rules sets should not be a black box to the end user: developers should design them not just to make styling work, but also to allow end user customization/interaction. There, panda allows only half of it (the ”make it work” half).

But if all those constraints are ok for you, panda may be a relevant alternative to Vanilla Extract here.