Maybe I'm going out of a limb here, but wasn't the whole point of CSS to not have to touch the markup when changing the styling? Not trying to talk Tailwind down, I have just missed a lot of the evolution of web design in the past 15 or so years.

Yes. Tailwind inverts that axiom to great effect. It's leaky on purpose.

Yes but the way we do HTML has also changed–for example by using JSX and reusable components. The issue of having to change markup in a lot of places to change styling doesn't exist anymore if you abstract that away in reusable components.

And using tailwind without a reusable components system is cumbersome to say the least. What is suggested in the documentation is to use editor features (multi-cursor, research and replace, ...) https://tailwindcss.com/docs/reusing-styles#using-editor-and...

Everything on the web became a lot more dynamic. Stuff like web apps obviously but even relatively straight forward info pages end up with dynamic filtering and elements of app like functionality often.

Given that, the separation becomes more of a pointless burden than actually doing anything useful.

I've never understood the point of separating markup from the design. I've seen CSS Zen Garden and... neat? But I don't get the point in real-world use. I've never had to redesign a UI in a way where I'd only change CSS and not also be moving around markup in the process. And once you're changing both of those things, there's the overhead of cross-referencing and keeping names and hierarchy in sync. At that point I don't know why I'd want the 2 separate.

The most magical moment for me when I started using Tailwind was realizing you can simply cut-and-paste an arbitrary block of HTML from one place to another and have it just render exactly as you'd expect. You don't have to additionally copy-paste a block of CSS, and then fudge around with the selectors because in the previous place it expected to be in some parent container or what have you.

The question of where to put the styles boils down to "do your content and style people work in completely separate teams?" For a newspaper, this is true. For someone who got their mate to set up their blog, this is true. Early days web was mostly like that. Not any more. If it's the same person doing it, put it in the same place. Separation will just be a hindrance.

It still is mostly like that, the content is not the html, the html is the presentation layer, as much as the css.

The content will be inserted from an API or with a templating system.

I want to see the company where the HTML and CSS are handled by separate teams.

it really only would make sense if we were serving pure xml and the webpage was the api for literally every webpage.

since that is not the case, tail wind is great, even the biggest complaint about tailwind, bloated html size seems like something you can just compile away.

> it really only would make sense if we were serving pure xml and the webpage was the api for literally every webpage.

This is, of course, XSLT, which was supposed to take over the web at one point.

https://en.wikipedia.org/wiki/XSLT

That reminds me the pitch for the first time I discovered css zen garden: "you can redesign your website without changing the HTML!"

I sort of liked it at first. I even added the opportunity for my users to modify the CSS to add new styles, and share these to other members of the community via a configuration page. It was a neat thing but not many people bothered and in the end it made everything more complicated (and I guess I was really scared of vulnerabilities the whole time, what can go wrong with letting your users set the stylesheet.)

Worse, I think this new approach broke the web as it was: an explosion of flash-layout or photoshop--or-fireworks-cut-layout websites. It used to be beautiful. Now the web is just a series of websites styled by CSS. It's sad.

phones (and their screen size + apple killing flash) really killed the beauty of the web IMO. Now everything's an app.

Well you have that CSS zen garden thing nowadays. It's all the different media, screen sizes, user preferences. And instead of writing multiple classes that defines styles for different outputs you just have one and let CSS handle the differences. No need to duplicate classes, just semantic names.

That was back when XML was supposed to take over the world. We were going to style the same semantic content for print and web with CSS and/or XSLT. XHTML was the next big thing.

We're not living in that future.

But the CSS ecosystem is still useful, and still adapting to our needs today. Tailwind might be considered one of those adaptations.

The sad thing is, the one good thing to come out of that swamp (xpath) isn’t used nearly widely enough.

> The point is not to hide the complexity of CSS, but to provide access from the markup to enough of capabilities of CSS that you don't have to edit your stylesheets 95% of the time, when you alter the styling of a document.

This makes Tailwind seem like a lot of machinery (in the sense of bundle size, running code, and pseudo-language) just to avoid opening a file at dev time.

Layouts are often "collaborations" - the effect of multiple items interacting. You'd still need to open multiple files to understand what was going on. Or read the DOM in the browser. When I read component code, I almost always prefer it when the style _isn't_ in the same file as the JS. It takes up space on the screen and gets in the way of reading about the behaviours.

I don't get the propertied benefits. Granted, I've still not used it.

Really? Tailwind sucks but that's literally the only good part of it.

Locality is one of the most important things in code. If I'm reading line 38 of foo.js and something elsewhere in the app effects that line, I want that something to be on line 37 of foo.js, not line 158 of bar.js.

The problem with Tailwind isn't the co-locating of HTML and CSS. It's that it does it by adding an entire new layer of complexity that's basically a copy paste of an large standardised API with the names of everything changed. It's barely even an abstraction.

> This makes Tailwind seem like a lot of machinery (in the sense of bundle size, running code, and pseudo-language) just to avoid opening a file at dev time.

It’s not about avoiding opening a file. It’s about avoiding the risk and/or cost that comes from editing a stylesheet that applies globally. If you change existing rules, you risk breaking the layout somewhere you didn’t anticipate. Or, to avoid that, you treat the stylesheet as append-only, leaving you eventually with enormous files and selectors of ever increasing specificity.

Tailwind (or Tachyons) makes for ugly markup, but it solves a real problem, and it does it better than anything else.

But can't you do the same with CSS ?

If every selector in a file begins with the component class, isn't it the same as writing styles in the component JS file ? I mean, the only real benefit I see is the forced encapsulation in JS compared to "soft" encapsulation in CSS. But, it's something so trivial to learn and practice that the soft part shouldn't be an issue. And if it is, then it is time to learn some rigour, no ?

Instead of editing styling in CSS you edit styling in element classes. You’re still editing styling.

> The point is not to hide the complexity of CSS,

I think one could argue that the raison-d'être of tailwind is to hide the Cascading part of CSS, and along with it a lot of the complexity of actually using CSS.

And in a way that same paragraph/criticism could have been written about Geocities in the early 2000's. Yet the simplified but imperfect onramp made a hundred thousand people more quickly understand their way into web development (including myself), than they would have without it.

> that you don't have to edit your stylesheets 95% of the time, when you alter the styling of a document

And the problem with editing style sheets when dealing with document style, is?