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.
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
- CSS classes can be named on a per-component basis, according to one of the well-established naming conventions (BEM, SMACSS, or whatever). This does not require remembering the names of other classes.
- With the arrival of web components, styles can be scoped within the shadow DOM; and the name collision becomes a non-issue; as well as keeping track of _all_ the CSS that's written in the project. If CSS classes don't leak, you can focus your attention only on a given component and ignore the rest.
- Instead of CSS-in-JS, one could use CSS modules, which are just regular CSS with a build step. The relevant project-level (site-level, page-level) constants can be defined as CSS constants on the root element.I don't see the advantage over inline style tho. I see abbreviations as a disadvantage as its just as fast to type background as it is bg but background is clearly more intelligible.
How do you deal with side effects for example I think bg-red is the brand red but some one has modified that class so it now has a border. You could prevent this with convention but then you have the same issues as using css with specificity and people not understanding the conventions around it.
I think its easier for every one to just force your frontend developers to just learn CSS and use it.
The biggest advantage over inline styles is that you are constrained. The idea is that you set up the primitives for your application's styling system: which colors are in use, which font weights, all the way to things like which border radii are valid. Your devs can then only use those.
You are correct that theoretically you can modify them to do anything, but in practice I find that people are extremely unlikely to violate the scheme (in ways like you described, adding a border to bg-red).
As for abbreviations? I think that's probably just eye of the beholder. Since you tend to add a lot of these to your HTML it helps it not get too ridiculously out of hand.
I spent years working with more traditional CSS schemes (including my all time least favorite, BEM), and it was pretty consistently a nightmare within the context of component driven applications. For a while now I've worked with tailwind and it feels like a massive step in the right direction.
I think it's one of those things that really doesn't make sense until you try it and feel the difference for yourself.
Really? I'm not sure I could take someone seriously if they called themselves a frontend developer and did not understand CSS specificity.
A program can read what looks like inline css and produce class names for youand put those in class files.
When developing your see "height 20px" In your app its compiled to "h-20" with a css file "h-20: height 20"
This is better because you don't have to learn another way to express the same logic.
Which is why this is basically reinventing inline styles. With some shorthand.
How did we go from removing <u> and <b> to calling it <div class="bold" an improvement?
You could do it with a cascading approach, but if you're building a component based application (this is what Tailwind is really for) then you already have an abstraction for re-usability. Trying to layer another one on top usually results in a really difficult to reason about mess of interlacing components and style classes.
In short it's a way to use an inline-type styling approach, which is suitable for component based apps, without giving up the ability to constrain developers to a limited design language.
There are a TON of other benefits for utility classes over inline, but I think what I described is the biggest one (media queries, pseudo selectors, stylesheet caching for reduced page load, etc.)
> How did we go from removing <u> and <b> to calling it <div class="bold" an improvement?
You can still use <u> and <b> if you want to. Adding a utility bold class also works fine.
That's exactly what it is.
But... you have to do that regardless of what you use for CSS layout. If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remember what you called them. Hopefully you're good at that and you can remember, else you'll duplicate things. Hopefully your entire team are aligned on the same naming conventions, or your project's styles will be a total mess.
Maybe you'll use styled-components or another CSS-in-JS solution, which helps a bit by making your styles scoped to components so they don't interfere with things outside of where they should, but then you'll have to keep a set of constants to use across all of them anyway, which puts you back at the same problem as plain CSS - you need to remember what's been set, and not duplicate things.
Ultimately, Tailwind is a really well designed abstraction of inline styles that means you don't have to worry about inconsistency and duplication of things any more. It's another thing to learn but because it's so similar to raw CSS it's not actually a lot of effort. It works well.