Senior Staff grey beard: Counterpoint: The C in CSS stands for Cascading.

So you’re not learning CSS. You’re learning Tailwind specific classnames that expand to non-cascading style rules.

This is not true. There's no way to create a "non-cascading style rule" unless the style rule already doesn't cascade. You still have to understand the cascade in order to use Tailwind.

While it's true that there's no way to create a "non-cascading style rule", Tailwind allows you to mostly ignore the cascade (except for the normalization stylesheet), because everything is effectively an inline style.

That said, ignoring the cascade is a strength, because the first step in the cascade (css selector specificity) is remarkably complex [0], and can be a source of errors.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

> You still have to understand the cascade in order to use Tailwind.

Can you expand? I haven't used Tailwind, but from looking at the docs, it looks like a short-hand syntax for writing inline styles. Not exactly the same since it can take advantage of media queries and other things that you can't do with inline styles, but close enough conceptually.

Where is the cascade with Tailwind? Perhaps I completely misunderstood how it works, but I would say that it feels like it's purposefully trying kill cascading.

There are two different things people could be referring to when they mention the "cascade".

One is CSS style inheritance. So if I do this:

  <div class="text-blue-500">
    <i>hello</i>
    <b>world</b>
  <div>

The `text-blue-500` style is going to cascade down to the descendent elements. That's just how CSS works and there's no getting around it.

The other usage of the term applies to a style of writing CSS that makes use of this cascade. So something like this:

  .card {
    color: darkgray;
  }

  .card .header {
    font-size: 20px;
  }

I think what people are referring to in this thread is the latter, which is not the cascade, but a particular approach to CSS.

I mean, the top just happens because color has 'inherit' by default. The latter is specificity, and normally what I think of when I hear "cascading". But, it turns out that isn't cascading either [0].

Cascading refers to the order stylesheets have priority when loaded by the browser. Going to have to update my definitions for the future. I always thought cascading referred to how specificity worked.

Edit: no wait, specificity is part of cascading, cascading refers to the entire process of determining which style applies, including specificity. Inheritance on the other hand is not part of cascading. My definitions were right, don't need to relearn anything.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade

>But, it turns out that isn't cascading either

The order in which stylesheets are loaded and it's origin is just part of the cascading algorithm. See the "Cascading order" section https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade#cas...

In truth everything mentioned above is part of the overall cascade. CSS takes almost everything into account - stylesheet ordering, rule ordering, rule specificity, etc.

the cascade has as many benefits as it has drawbacks, few people like to juggle specificities.

IMHO the only important application of the cascade is in its original purpose: custom user defined stylesheets (today often via browser extension or adblockers), but you can add proper descriptive attributes to your markup for them.

In today's uses, cascade _with_ custom properties (the vars defined within :root ) are powerful and are what I leverage when providing theme-able ui libraries. Dark mode, light mode, large mode can all be solved using custom properties which to me most exemplify the power of the cascade.

that is inheritance not the cascade: Inheritance allows for DOM nodes to use properties set on their ancestors, the cascade algorithm is how multiple conflicting rules interact and are overwritten.

https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade

https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...

Custom properties are by default inherited by all descendant nodes (they also interact with the cascade, but it is less relevant) and this can be used with tailwind in a couple of different ways: https://stackoverflow.com/questions/64872861/how-to-use-css-...

Mid level beard: Tailwind makes most sense in an app developed with components.

So the cascade still happens, just in a different way.

Styles applied by Tailwind cascade like any other styles.

You're not the first person to mention that, to which I counter: Cascading is a mistake in today's component-first web. It works at a very small scale, and _sure_ some things should be cascaded—which Tailwind absolutely lets you do. But 80% of your styles are going to end up scoped to their component—so you might as well use a tool that leverages that concept to its fullest extent.

All my "hard opinions" aside, I have anecdote that no amount of facts can change—I build things faster, more maintainably, that look BETTER than anything I did before Tailwind. Until those pillars stop being true—Tailwind will have my heart.

> And no one (good) picks up a tool solely because it’s shiny

The amount of cargo culting going on right now is at an all time high. People do stuff all the time that makes no goddamned sense and is defended by, “well Google is doing it!” You are not Google and you never will be.

>The amount of cargo culting going on right now is at an all time high.

In fairness, CSS is such a mishmash of things that it lends itself to cargo-culting.

You can fit the number of people who are exclusively CSS experts in a van and still have room for their luggage. Everybody else is going "that's cool, how do I do that?" and then copy/pasting it.

I mean, hell, it was years before you could reliably vertically center stuff with CSS (that we were doing with table-based layouts since the 90s). And considering the number of wonky layouts I've seen in what should be professionally done mobile Web sites, it's clear that it's hardly a Done Thing.

The nerd in me really likes SCSS, because I can more or less wrap my mind around it, but I get the Tailwind way as well. As a developer, CSS is way down my list of things to know intimately. Whatever I have to do to keep things moving, I'm good with it.

Emphasis on "good". I don't classify developers who base their decisions on "Well Google is doing it" as "good".

I vehemently disagree. When you're using tailwind, you're learning Tailwind, which is using CSS in absolutely the unequivocally anti-CSS way.

CSS was meant to cascade; it's what the damn 'C' stands for, and if you cannot understand the efficiency of the cascade, at scale, you are most definitely missing the entire point of CSS.

I have personally built ui libraries for boutique firms and enterprise (Apple) firms and guess what we did _not_ use in any of those instances? Tailwind. Because it's an utter toddler to manage and very definitely not efficient in its application.

There's a strong contingent of developers who would argue that the global-by-default aspect of CSS was a mistake. Hence nested selectors in Sass/SCSS, CSS modules, and so on.

Styles applied by Tailwind classes cascade. The library just makes it (intentionally) difficult to define a class that will easily collide with others.

Actually, the "C" in CSS stands for "Mistake". Cascading styles are not a good idea, and Tailwind encourages using styles in a way that makes sense for a component-first web.

If you want to cascade all your styles all the way down, by all means go for it. However, I aim for readable / scalable styles rather than dogmatically "cascading" everything just because it's in the name.

Yeah, I always describe tailwind as a lightweight classname-based abstraction over native css rules. It's a _good_ abstraction because it doesn't obfuscate the actual css rules; you're still wielding css when you use it. Colocating styles with components using short hand for css rules is brilliant and now that I've tasted it, I'm averse to our tradition of hiding things behind a bunch of subjective class names in a different file. Not too mention the optimization of removing unused styles based on the classnames used. Tailwind is good

yeah i'm only able to use tailwind because i know the fundamentals of CSS

Most CSS codebases just like most JS codebases are low quality. This is a reflection of process more than anything else.

TailwindCSS puts a bottom threshold to the low quality - it guarantees a minimal level, regardless of what the rest of the codebase looks like.

This comes at the cost of general (but limited) messiness and guaranteed lack of maintainability.

I don’t use it but if I was on a team where engineers don’t talk to each other I probably would.