Simple linting rules can get you lots of mileage here. First and foremost, you ensure that in any component CSS file, ALL selectors begin with a class that mirrors the filename.
It seems to me that this can prevent the vast majority of conflit or spillover occurences. Don't you think?
> First and foremost, you ensure that in any component CSS file, ALL selectors begin with a class that mirrors the filename.
But then you're adding a convention that isn't as easy to follow. Maybe you follow it, but what about new people. What about people who make a typo? Are you going to make a VS code plugin that points out if someone mistypes the file-based class in the CSS file?
What if the file is renamed, or moved? Do you then have to go update every selector in the CSS file?
This all seems so much more brittle to me than just using tailwind, and the VS code plugin show you the possible class names you can select from when you start to type something, as well as rules for each of those class names. It also catches (and highlights) contradictory rules, when applied to the same element. You can't do that from the CSS (there's no telling what the declaration will be used for, from the css in isolation), and unless you make your own editor integration, this won't happen when editing markup either.
What is the convention? Beginning selectors in a file by the filename only? If I understand correctly, then I'd fallback on the linting.
If the file is renamed, then yes, you change the selectors. That's a simple operation. But I think the same goes for any JS framework where you'd create components. If you change "button" for "secondary-button" you'd have to change it in at least a couple of places I guess? Either way, you should limit these kind of operations to a minimum.
And what if I don't want to use VSCode? Maybe there are Tailwind plugins for every text editor...
But more importantly, that's quite easy to include your CSS files in the autocompletion of, for example, Sublime Text. I'd guess it's the same in VSCode. And again, simple linting should prevent much of these problems I think. You can easily lint contradictory rules in a ruleset. Stylelint would be perfect for that.
And if by mistake you have contradicting rules across rulesets, then a quick look at the devtools will tell you where the problem comes from. On a sidenote, the devtools become real difficult to use in a Tailwind-like paradigm.
> If you change "button" for "secondary-button" you'd have to change it in at least a couple of places I guess?
I'm not sure I understand this argument. If I rename a component and the file it's in, I get automatic import renames across the codebase without having to do anything myself. And if I didn't, I'd get errors trying to run the code (I'm not sure how you'd configure CSS to do the same thing with unmatched selectors, though I guess you probably could remove them from the output at least with postcss)
> And what if I don't want to use VSCode? Maybe there are Tailwind plugins for every text editor...
They removed the question so I don't know what current trends are, but Tailwind is at least supporting 90% of possible users with just those 2 (and I haven't looked into support for other IDEs)
> On a sidenote, the devtools become real difficult to use in a Tailwind-like paradigm.
I haven't found this to be the case at all, I'm not sure why Tailwind would make the devtools more difficult. If anything, it makes it easier since I typically only have to look at the CSS section for elements which have inherited styles
A simple find and replace would do the same then for a CSS change. Again, that's not something that should happen often.
As for support in text editors, you can still autocomplete any class you have in your CSS. And the CSS linting will give errors too if you have problems. And there are CLI programs for discovering unmatched CSS, which works pretty well in my experience.
And the devtools suffer from all the added classes. It can slow down to a crawl depending on your machine. And you can't play as easily with the styles... If I disable a property in the cascade, all other items with this property will lose it. I would say it goes against the devtools grain. But I guess it depends on your usage.
Simple linting rules can get you lots of mileage here. First and foremost, you ensure that in any component CSS file, ALL selectors begin with a class that mirrors the filename.
It seems to me that this can prevent the vast majority of conflit or spillover occurences. Don't you think?
Legitimately curious here as well!