Before CSS, layouts were implemented by abusing table elements to create a grid. Then images were sliced up into sections, and each section was placed into the table. This has generally been remembered in the present day, however what seems to have been forgotten was the pushback against CSS.
There was a large number of web developers who were happy with the status quo and refused to learn CSS. One of the most persistent myths was that you couldn’t make anything look nice with CSS. Specifically, CSS was accused of only being able to create “boring, boxy” designs.
It wasn’t true at all. Even back in the early days of CSS, you could create great layouts. It was especially absurd because the approach favoured by the people saying this was literally abusing tables to create grids.
So along comes Dave Shea and points out that this is ridiculous, that CSS is capable of great designs, and puts the CSS Zen Garden up. A whole bunch of people contribute good-looking designs and make it impossible for people to claim that “CSS can only produce boring, boxy designs”. I think it’s amusing that he won the argument so conclusively that people forget it was even an argument in the first place.
At least though, these extra DIVs weren't disrupting the page layout (eg. when disabling the CSS - something that was still possible at the time), which was beneficial for accessibility.
I still remember the campaign for sites to drop support for IE6 in protest.
I kept our internal reporting site running for 3-4 years, I used CSS for layout.. it required regular maintenance but I had enough time to do it as my main job was as a Database Admin / Data Engineer (I'd have been called "devops engineer" nowadays as I had quite a broad set of responsibilities).
[1] https://90s.dev/
I think media queries/responsive is what did in the last bastion of CSS resistors.
But then, neither were tables.
Never understood what was actually wrong with it, apart from the whole "semantic html" yadda yadda that is meaningful for a small subset of applications.
I am surprised people here still hold on to that era of CSS. There are even people in the comments being proud of clearfix
But I should probably be thankful for CSS for getting me out of webdev early :)
> Never understood what was actually wrong with it
Separation of concerns?
> The standard pointed out that tables could be used for tabular data or layout purposes, but cautioned that using them for layout would impact accessibility.
> In HTML 4 (April 1998), this warning was strengthened to "Tables should not be used purely as a means to layout document content", and we were pointed to the addition of CSS1 to help accommodate this. It was noted, however, that using deprecated features was expected to continue for a little while [heh] in order to support older browsers (browser listed above).
https://www.tiernok.com/posts/history-of-html-table-layouts....
CSS Zen Garden is a project that demonstrated that "progressive enhancement" and "semantic HTML" were nonsense. The only reason something like CSS Zen Garden worked at all is because all the markup is fixed, all the content is static, and the designs are not really responsive.
There is no CMS with a theming system that offers the flexibility that CSS Zen Garden claims one can have with a single .css, independent of the HTML. And this is because web developers were huffing the HTML/CSS gospel too much, fussing over not having extra divs in their source and what not, and celebrating "semantic HTML" without ever running their website through a screen reader.
The reason people stopped using table layout when they were doing CSS is because CSS1 did not support the _most common way of doing layout at the time_, and IE6 held the web hostage for a decade. This is a remarkable thing because it means everyone hopped on this bandwagon despite it being very obviously ill-informed and not ready for production. The CSS Zen Garden era designs can be expected to be full of float/clear tricks, requiring careful layout dependency between elements so everything gets pushed down just far enough. And it looks exactly like the table-based layouts they were replacing, except they will scale improperly or not at all.
The "status quo" attitude has also not vanished, as witnessed by CSS variables, custom properties and all the other epicycles that keep getting added on to CSS instead of actually just scrapping the parts that are dumb. None of these CSS experts have the vision or depth of experience to really know what it takes to implement what they spec, or what is even still relevant today and what isn't.
I actually implemented my own web layout system for Use.GPU from scratch, with flexbox and blackjack and hookers, and it's remarkable how much of HTML/CSS you don't need, and also, how many parts of it are still laughably inadequate (like text-ellipsis).
Dave did not win the argument. The people who celebrated CSS Zen Garden were cargo culters who confused a pretty design for a structurally sound layout, and who honestly just wanted something they could feel good about while dealing with pre-Firebug / pre-Dev Tools CSS development.
There is a really easy way to test this too, and I would challenge Dave to do it: translate all the content to another language. See how many of those beautiful CSS-only designs fall apart.
I wonder whether we'll ever get to reach this point with Safari. Especially with regards to PWAs and the insane state of "native" apps.
This site was a "culture" shock for me, back in 200x and made me walk away from Microsoft ASP.NET and start building apps on linux, realizing all those "server controls" with inline style parameters were basically the complete wrong way, the "anti internet way".
It was Alex Russell (creator of Dojo JS) who showed that side in one of the conferences, and I was shocked how much information I was missing while getting my technical news through Microsoft channels.
For many years, my toolkit was simply Web.py, HTML, JS and CSS.
We then got jQuery, and Backbone, and Underscore, till the React and then TS made new "Full stack" dumber again.
What stopped you from building such apps on Asp.net? It didn’t prevent you from building anything like that. You could stop creates style sheets and separate JS files.
> realizing all those "server controls" with inline style parameters were basically the complete wrong way, the "anti internet way".
Ironically what’s old is new again because we have literally gone full circle even down to nextjs? Recreating view state… and tailwind with inline styling and shadcn with react components.
That's still online, although as an outdated relict: https://www.ajaxtoolkit.net/. There was no enterprise software without drag panel!
For a moment semantic markup and CSS had taken the lead but nowadays I don't even care enough to check what the trends are. Stopped caring around the moment of "HTML inside JavaScript" (JSX).
You didn't need to switch to Linux either; I built everything under Windows (IT didn't allow Linux desktops) and deployed it to both Windows and Linux servers.
While you can still do this to the extent zen garden does, it's really operating within the limits of css (i.e. css can do this, therefore I can create this type of design, not I want this type of design, therefore I need to write this css).
There are lots of style choices that require modifying the DOM directly to effect, and can't be done purely with CSS. I've seen discussions on W3C where it was like "Well if you add another div around this you can achieve this effect, so why do we need a new CSS property?". Stuff like inserting or swapping an image is simple, but swapping a styleable SVG is impossible because the SVG nodes need to be directly embedded in the html.
So you're forced to mix presentation and content structuring decisions at the HTML and Javascript levels and even some simple design changes require modifications throughout the stack.
After my 30 years of writing GUIs, I'm now convinced that this is the wrong place to draw a dividing line.
Instead, we should be isolating intent. This is what Composites do in my project. I'm so excited to announce it next week!
The HTML is littered with styling information. Reading HTML should be about content and meaning, not knowing that "pl-16 pr-8 bg-olive-500 text-gray-700" means "this is probably a card header". But... you might argue that people do not read HTML anymore. Yes, people don't read HTML anymore. Who would when the devs using this framework turn the HTML into a horrible mess! If you litter your HTML with so many framework classes, there is more noise than content in HTML. Is it a surprise that reading HTML has fallen out of fashion? And since nobody reads HTML anymore, devs are totally unhinged with cluttering it with more and more classes and styles. It's a self perpetuating cycle.
Webdevs do style duplication rampantly. Instead of something like ".button", you'd find stuff like "text-white rounded bg-gray-aaa" littered throughout hundreds of places. I'm not sure if this is a Tailwind problem or dev problem but the problem definitely is there. A large project would soon reach a situation where if you want to make a style change across all similar UI elements it's a whack-a-mole game to find out which inline styles in which elements you need to look at.
Conversations about CSS complexity always remind of this quip: "Two CSS selectors walk into a bar. A bar stool on the other side of town falls over."
Nowadays the anti-@apply contingent seems to have gone quiet, so it is possible to not only use TW and similar toolkits sanely (which has always been the case) but to even see people publicly advocating for sanity.
now multiply this problem by more people working on an app, with different isolated components that they never even dreamed of during css zen garden's time and this is how something arose. we've tried creating centralized css sheets and it just doesn't work at scale.
so yeah, a necessary evil, but i wouldn't call it an anti-pattern. it grew out of real needs. we had bootstrap and all these css frameworks attempting to make "order" about of something that honestly after decades of working with i don't think can be ever be fully "clean". people just gotta move past it.
What changed things for me was reading an short online book-style series about learning HTML/CSS from the ground up. It introduced everything from first principles, and had an approach where they explained why things were the way they were. They didn't just give you their "top 10 ways to center a div" and ask you to leave. I read the whole thing in an afternoon and it changed the way I think about web development. For the life of me, I can't remember what the book was called. If anyone's read something similar I'd love a reference, it was a while ago now and I'd still like to reference it. I specifically remember them saying "display: block is like a word document, and display: flex is like how you'd expect things to work," which illuminated a lot for me, not just about the display property, but generally about the way HTML & CSS were designed.
It's difficult to realize how significant CSS Zen Garden was 20 years ago or so.
https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-...
Edit:
See also this thread on Bluesky
https://bsky.app/profile/infrequently.org/post/3lnehf53bpcl7
When I got productive with Tailscale, I finally realised how many brain cycles I wasted on this. I’m, like, a programmer; of course I’ll obsess over picking the perfect name. Of course I will not be happy with the names my junior picked, and of course I will constantly be unhappy with some of them. This game of self-inflicted bike shedding is just a trap for people that like logic and order, and it’s… wholly irrelevant.
With tailwind, you just declare how something is supposed to look and feel like, at the place where it is, in the context of your configurable design system. No names, no bike shedding. Okay, that’s not a hundred percent true; you can name group selectors, because as opposed to plain inline styles, Tailwind can target children, siblings, pseudo elements—there are no restrictions.
It’s a truly elegant solution for authoring web pages.
I know the joke is that naming things is hard, but it really isn’t and every web developer successfully and effortlessly names things all day long without even thinking about it.
If I have a sidebar, coming up with the name “sidebar” for a CSS class is not a serious problem I need Tailwind to help me avoid. I don’t find it plausible that other people genuinely feel pain over this one particular instance of naming things without demanding solutions for all the other things they have to name. Can you point to many Tailwind advocates who complain about how difficult it is to pick filenames, or page URLs?
I think it’s really strange Tailwind advocates latch onto this one particular thing – naming things is a problem – when they seem to successfully name things all day long in every other context. It doesn’t feel like a real problem. What happens when you need to create a file? Do you get paralysed by the myriad choices of filenames available? Or do you just pick a name and move on?
Add to this that CSS is like a codebase built on try/catch and throwing errors for its primary control flow mechanism, where the only thing that tames this is the naming conventions employed, and you've got a situation where the names really matter in a way that they don't when we're doing other programming, because the names are the only connective tissue to help you reason about the "control flow" once your css starts getting complex.
Tailwind is made for the age of apps and components. The semantics are on component level.
It’s not about not being able to name all these things, it’s that it’s pointless to do so.
My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive.
Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less.
> Tailwind [is] a path to ruin.
Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat.
For me, styling on the web is solved.
Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS.
> style bundling an issue unheard of
But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.
So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...
The one that hasn't been available in CSS until 2023?
> So you name you conponent and use selectors for styling sub components.
So how can you do that with CSS?
CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years.
What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952
Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/
And as a bonus it provides best practices in css scaffolding of a product design (typography, grid, colors)
For instance now I have class some-button to make the button blue. Next week I‘m told make them yellow.
It’s a change in one class
What would be the equivalent in Tailwind?
Your components are styled using these spectrums - button.color-primary-500.bg-grey-300
When you want to change the colors globally it’s extremely simple.
Same with paddings and margins.
It's somewhat similar to raw HTML vs something like PHP, you can have thousand of HTML files, but if you wanna change something common (say the header) it's not fun with thousands of individual files.
Lastly you can combine Tailwind with regular css classes
.btn-primary {
@apply bg-blue-500 px-2 py-1;
}
Personally I think it gets a bit mad when you start wanting to do :hover, :active and media queries, but you can still use classes (using the @apply directive) for that if you wish.
i can't tell you how frustrating it is to open a component and have no idea what you're looking at because you worked on the thing months ago, or you change one thing in your centralized CSS and have no idea what the side effect are. with tailwind i can see exactly the styles i'm looking for.
FOR ME, works better to have a core style file and then move everything to something like tailwind per component for maintenance.
tired of seeing the same simplistic arguments against utility frameworks. if you can't see the merits of it then you obviously aren't working on projects that need that, but don't criticize it blindly. it's not for lack of CSS knowledge.
Like "side-effect" you mention. That can only happen, if the design is implemented reusing parts of other design definitions, where they are not meant to be reused. Any other side effect would be intentional. For example button text color and paragraph text color. If one wants them both to change, when one of them is changed, then one reuses the style definition, but probably in most cases one does not, and therefore has separate definitions and therefore has no silly side effects, even after a few months not looking at the project.
back in the backbone days, now vue/react and before tailwind this is EXACTLY what we did, scope the styles down to the component, then layer it on top of the global styles. so sure, .my-selector a is specific to that component.
the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions.
so with that out of the way, let's say you do get your global styles like 90% of the way there. so in each component you scoped it down. now lets say for one button you had to adjust the margin a bit, or another the styling is somewhat diff. multiply this by 100s of different components.
tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component.
at some point you can't possibly create the number variations you need and you can't extract out "reusable" parts. maybe you have 5 buttons and only 2 need the 20px margin. do you create a "button 20px" class and do that in each component? no. at some point you will just inline it because it's easy, or you will create your utility class except it will be worse than tailwind.
It also enforces a design system (spacing, colors, fonts), while inline CSS often leads to small, inconsistent differences everywhere.
It’s a great solution to a problem a lot of people were having. That’s why it’s so popular.
Then you can also use @apply if you wish but leave that out of the argument as it is considered unidiomatic.
Of course if using React you can also use styles directly and then create your own utilities to determine how they compose. Which might give you much of the Tailwind edge without needing the compile step.
For those who don't know: for the same html content you could submit a design in CSS and images. For example these impressed me the most:
- https://csszengarden.com/202/
- https://csszengarden.com/189/
- https://csszengarden.com/177/
- https://csszengarden.com/136/
- https://csszengarden.com/206/
There was also one which had a position: fixed knife "cutting the page from the middle" when you scrolled, but it doesn't seem to be on the list anymore. Edit: and another one I remember was like so that the top of the page is sea level and you'd scroll to the bottom of the sea, where there was either an octopus, a submarine or a diver, can't remember.
But I've also got to rant now.
What I find most troubling about Tailwind and CSS "frameworks" like it (and modern software development in general) is the growing pride in not understanding the underlying systems.
Tailwind offers a quick, surface-level solution: you can slap some utility classes onto a page and get something that looks "good enough" without ever learning how CSS actually works. Nevermind that the HTML is now a mess where you've got more CSS classes than content!
The attitude is, "Who cares how it works? I got my pretty page. That's a win!"
But this isn't just a Tailwind problem. It's part of a larger trend in the industry: celebrating ignorance, rushing for results without building real understanding.
When did not knowing become something to be proud of? Isn't it sad that depth and mastery are now treated as optional, even undesirable?
/rant
It's very concerning when software developers neglect that their tools (abstractions) have tradeoffs.
"If civil engineers built bridges the way software engineers build applications, the bridges would all fall down in a month".
And similar sentiments. Granted, most things aren't mission-critical, but then just because my house won't collapse doesn't mean I want to waste money on poor insulation and broken appliances.
From what I've seen across multiple teams, it's very common for developers to just slap Tailwind onto their project, copy-paste classes they found online and call it "done." Maintainability and reusability are treated as someone else's problem.
we are still living in this world. and i don't mean it snarkily. beside some maps application, most of the web is still about reading stuff, and it doesn't need so much cruft. it's getting more complex just because developers prefer complexity over simplicity.
CSS Zen Garden was about styling “web 1.0” HTML documents.
But dynamic UIs have completely different styling needs. People started building JavaScript applications, and they started needing UI layouts similar to those provided by desktop UI frameworks. And CSS was never designed for that. Concepts like “float” were entirely derived from the word processor universe. CSS had to add several complex new layout engines over the following decades.
Now server side rendering is all the rage again, maybe we will also see a comeback of semantic html and simple stylesheets.
When multiple different CSS layouts depend _deeply_ on the specific structure of the markup and the markup _needs_ to change over time, at the least you're in for pain, and at the most you're hosed/rewriting.
Maintaining CSS is easier than picking through markup trying to catch all the class names, especially if you use a preprocessor with nesting.
Admittedly in my professional experience, CSS-only refreshes are rare, but in my case only because it's been more common to change the content at the same time.
The markup shouldn't need to change over time in a way that makes the CSS layouts not work because it just reflects the semantic structure of the document, which shouldn't really need to change. If it does you have quite a different document and so of course it will need CSS changes too.
I was always much more afraid of touching ad-hoc CSS that was written alongside HTML, because it ends up having all these classes and elements that have no semantics and it becomes very unclear what anything actually means. The very worst is the "tailwind" styling where classes etc mean nothing, just styling.
Similarly, it was ExtJS that made me realise that web sites could be just as good as desktop apps.
https://svelte-zengarden.netlify.app/
(click and drag on the writing hand emoji)
I wonder what year this last was true.
One of the best websites back then, id guess even today?
it was enlightening to work through this book, i even got a hardcopy of it from the local library while being a student
Keep the Zen Torch on.