The thesis of Tailwind is that the cascade actually becomes very unclear and inelegant at scale, and I would say the reason it's so popular is that many devs share that experience.
But the opposite is largely true for UI elements. For one, I’m probably using some external templating or component framework to repeat them, because they mostly likely have behaviour attached and HTML by itself has no good story for that. For two, I pretty much never want their styling to be modified by the context in which they’re used.
But that’s what you’re doing when you use scoped styles, components, Tailwind etc.
Just set it once, on body and forget about it for the lifetime of your app.
> I pretty much never want their styling to be modified by the context in which they’re used.
I guess we have worked on different projects. To me this sounds like the edge case. Most projects I’ve worked on want all the components/widgets/thingies in one consistent style that works together for a cohesive overall experience. For such situations (which to me feel like the majority case) the cascade is the simplest tool.
This is the distinction to me. New methods in composing a page approach this differently: style consistency is maintained through dependencies and a build process rather than relying on context. To understand the styling I'm applying to a given HTML elemnt, I can look to the packages going into the build (just as a I do with other aspects of the code) rather than needing to understand every context my component could possibly be invoked within.
<Button class=`border text-gray ${override}`/>
<CalloutButton /> extends <Button override="text-blue" />
I'd argue you have less markup to write overall if you are modularizing component logic/styling
for example if the corresponding css file is this: .text-blue { color: blue; } .text-gray { color: gray; }
Then in your above example, both Button and CalloutButton will have gray text because .test-gray has higher specificity than .text-blue
This is true. But if we better taught the cascade and promoted the idea of global styles rather than pretending it's a problem then more people would be better at this and the problems would gently recede.
We (the high-end front-end dev community) have fallen into the habit of using class names where we really wanted IDs and using components when we really wanted global styles. I feel we have been pushed in this direction by developers who didn't understand the technology properly. The Tailwind author clearly understands it, so I'm not targeting them... but they are supporting the people who don't see why the cascade is useful.
We have megabytes of code to create the impression of global consistency (components, style libraries, CSS-modules...) shipped to millions of users every hour. Browsers do that for us already. Embrace the simplicity of
button { border: foo; color: bar; } .callout button { color: aux; }
It's so clear, so elegant. The obsession with modularising everything, and then applying a DSL to get between the modules, makes the language's inherent convenience, elegance and clarity so much harder to work with that it boggles my mind.