Hope he's doing well. Guys like him, Doug Bowman, Jeffrey Zeldman... all a huge influence on teenaged-me hacking away on my little blog and thinking of going to SXSW someday.
This was the site shown to me to prove the separation of style and content. After that it was CSS-Tricks that I found myself frequently reading for answers to the things I was stuck on getting the layout to work.
I can't wait for AI watermark checks to be widely available to stop such guessworks and the resulting ridicule. I'm not saying you're wrong, your guess could be.
Yeah, especially since we're exposed to so much AI-generated text these days, we may inadvertently pick up some verbal habits from it, the same way people tend to imitate each other. And needless to say false positives can be quite damaging here.
Pangram seems to be very accurate. I don't think that's a good thing though. Right now there is a lot of prejudice against AI users, and detection will only encourage that.
> Right now there is a lot of prejudice against AI users, and detection will only encourage that.
That’s exactly how it should be. If you serve me up AI-generated rubbish that I’m then supposed to sift through, you’ve earned the ridicule of the whole world.
Implies you'd accept it if it wasn't rubbish. Seriously doubt your filter is based on quality.
> you’ve earned the ridicule of the whole world
As if human writing immunizes you from that. Published an article about garbage collection and had people complain about my human voice. One went so far as to suggest I had mental issues. I received praise too but some things you just never forget.
Best part is Claude warned me repeteadly that I should tone it down, and I deliberarely ignored it in order to preserve my voice and keep it pure. I'm much more inclined to listen now.
If its substantially AI generated then it's definitionally rubbish, even if it was a good answer to the prompt. I can send a prompt myself, don't waste my time republishing AI answers.
Please define "substantially". Exactly how many words must come from my hands and brain in order for a work to qualify as human?
Imagine that I write an article manually and keep it to myself. Then I prompt my favorite AI model and it somehow generates the exact same article, against all odds, despite having never seen it before. Then I publish the AI's article, which is equal to mine. Is the article rubbish?
> I can send a prompt myself, don't waste my time republished AI amswers.
I can do it too. I consider it rude to reply to people with AI answers during conversation. Not because I hate AI, but because it made the social interaction pointless.
That doesn't somehow invalidate the value of an AI generated article though. Not everyone thinks to prompt it with that exact idea. Not everyone has an AI they can prompt. Not everyone wants to waste their limited tokens on the idea.
I realize that reading Claudish can be aggravating but that doesn't somehow eliminate the ideas contained in the article. Those can still be very valuable, which is why I advocate for quality filters.
That's a little metaphysical for my taste. If its the same bytes of text, provenance is destroyed anyways, so who knows if the tree fell in the forest.
"Substantially" to me would mean not your ideas and not your writing. I'm sure there are borderline cases that are hard to decide but a rule of thumb for me would be if it takes more time to read than it took the "author" to write.
It's about effort into thinking. If no effort went into either thinking or writing, then I'll plead guilty to sweat of the brow doctrine. Again, just send me the prompt and I'll feed it to AI myself.
Reading is about learning interesting new ideas, enjoying a narrative. The suffering of the author is beside the point.
I can sympathize with the notion that AI writing currently sucks, but not that it's automatically invalid or deserving of mockery. Maybe one day we'll have far better models. Maybe they'll do a good job without inserting any load-bearing vocabulary.
Asking for the prompts is fine, but might not be sufficient. The process iterative, and may incorporate data that won't be published. For example, I recently published a Sol/Fable benchmark article. It would be trivial for anyone to prompt a new version of the article if they had the raw benchmark data, but this data will never be published.
It's not about how good or bad the AI writing is. It's about the human interaction, if someone outsourced their thinking to AI then they are bullshitting me and I will rate their thoughts appropriately at the human level.
If someone's already burned the trees down to generate it once, why would you want to burn more trees, just so you can do it yourself? Do you hate the Earth or something?
I’ve never said that you don’t deserve to be ridiculed when you write human rubbish, but I haven’t claimed the opposite either. However, I do believe that you definitely and without exception deserve to be ridiculed when you produce AI-generated rubbish.
Analyze the game theory of what you just proposed. Have AI effortlessly generate an article for your idea, get ridiculed. Put a lot of time and effort into it instead, maybe get ridiculed anyway.
I appreciate the feedback. I did use AI to help me put this post together quickly. I've gone through today and manually re-written it. No more AI slop.
> “Then you tried to ship real client work, and the dream fell apart.”
For me it was here. I have tried for months to get AI to write for me and have now fully embraced the fact that LLMs are not ready to do that for me. None of them. I’ve gone back to writing my own content and only using the LLM to brainstorm.
This is really great work, but I think a lot of folks on HN don't look kindly on the CSS Zen Garden or that era of CSS. They think the markup/stylesheet separation of concerns was a terrible idea, an idea that Tailwind exists to fix. (I think they're wrong, that separation of concerns is good, Tailwind is a hack, and get off my lawn while you're at it.)
The point is - now the modern vanilla web platform really can support first-class CSS-styled app components, from design systems, in production. This is really cool!
HTML and CSS were originally designed as document-oriented languages for digital document display; think MS Word or PDF with cross-document hyperlinks, and not an app SDK. The idea was simply "style your web site's titles, headings, paragraphs, footers, etc. in just one place; change it there and the whole site will update". That's the dream that CSS Zen Garden was meant to showcase. Interactivity and web apps came later, and CSS has taken a very long time to catch up.
But catch up it has, and I'll be glad when frontend web development sheds Tailwind and React in favor of the updated vanilla web platform; and I won't complain if we use super light web component libraries like Lit[0]).
I agree completely. Personally, Tailwind never really resonated with me, though I've used it several times, and we did even briefly consider it for this project. I always felt that it was an approach created by people who never understood the paradigm of CSS, and didn't want to. Since my career started with CSS, I've always been more of a purist.
I think a collection of basic utility classes (w-100, m-2-t) and layout components (<Flex dir="row" gap="2">, etc.) are equivalent ideas, and they are nice for quickly setting up a one-off layout that's very readable. But Tailwind turns this practical idea into a religion that locks projects in to using it and harms readability.
Human readability is a very useful proxy for good modularity and separation of concerns (and modularity increases scalability and reusability). Since LLMs take the whole thing in at once, they are terrible at module boundaries. (They also suck at theory of mind, and their comments reflect it, but I digress.)
I see no connection whatsoever with the CSS Zen Garden dream. CSS Zen Garden was about applying radically different styles to the same markup. This is about newer CSS features like Custom Properties, Flex and Grid making maintenance of a single stylesheet for a single completely typical website.
This is a reasonable reaction. Thank you for pointing that out. I've updated the post with some thoughts on this. Basically, think the radically different styles part of the CSS Zen Garden was only how the dream was shown, but it wasn't the substance of the dream itself. The substance of the dream was to show the power of CSS, and what was possible with separation of concerns and browser support. And that's what I think we showed with what we build for Firefox.
I still remember being like 15 years old and seeing my website(s) land on CSS Zen Garden, CSS Thesis, etc... using Mint analytics (throwback! shoutout to @shauninman) to see all the inbound traffic. What a time to be alive.
Personally, I love the current Firefox.com design and see the simplicity as a feature. And it's designed to be responsive to any screen size. A design like this would have been incredibly challenging to build with CSS 2.0 in 2008. That's the point of this post. But if you find the design boring, just like the CSS Zen Garden, you can design your own user stylesheet to re-style the whole site, hundreds of pages in dozens of languages, into any design you want, with one stylesheet, because the styles are cleanly separated from the markup. Have fun!
Yeah... I was trying to figure out what he was pointing to, and was like.. oh, the Firefox website... went there and was pretty uninspired by the design, at least in desktop.
The CSS Zen Garden worked because everyone was using a single markup file. In real life, it doesn't really work.
Instead of thinking of separation of concerns as a religious principle, think about what benefits it actually yields in the case of HTML.
When the markup is completely separated from its styling, this means that the CSS rules need a way to be mapped onto the DOM. This involves specific elements, organized a specific way. If anything is out of place in the markup, the properties may not apply as intended. Similarly, if the CSS doesn't account for DOM structures, then you need modify rules or add new ones.
This way of mapping is an implicit structure. It's something extra that's required, beyond the source code that's there. It can be computed by the browser, but it's not explicitly stated for a developer looking at the code to understand.
Contrast this with Tailwind, Tachyons, etc., where nearly all the structure is explicit, less complex, discoverable, and out in the open.
Hidden structure looks nice to the developer. The code "looks" clean. But understanding a code base's implicit structure is ephemeral, and there's inherent technical debt that will need to be repaid later.
Tailwind looks ugly, but there are no hidden abstractions or structures in the code, beyond its easy conventions and a minimal config file.
And, yes, there are ways to make high-abstraction CSS work, say, with a component library of known DOM patterns. But at that point, why not build the styles into the components directly, a la Tailwind, instead of adding complexity?
> The CSS Zen Garden worked because everyone was using a single markup file. In real life, it doesn't really work
The dream of the CSS Zen Garden never really extended beyond itself. That wasn't the point. The point was to show people "look at all these pages that look nothing like each other: they're all the same HTML." That was the magic.
Keep in mind the context: you still largely needed structural HTML to effect the layout of your page. Almost everybody was building with HTML where the markup was critical to the appearance. Frontpage, Dreamweaver, and every other tool generated almost no CSS—or at least no good CSS.
This isn't my interpretation. From the site itself:
> There is a continuing need to show the power of CSS. The Zen Garden aims to excite, inspire, and encourage participation. ... CSS allows complete and total control over the style of a hypertext document. The only way this can be illustrated in a way that gets people excited is by demonstrating what it can truly be, once the reins are placed in the hands of those able to create beauty from structure.
More specifically – because I think this is an aspect that has mostly been lost to time – when the CSS Zen Garden was first created, table layouts were still the norm and there was huge pushback from a surprisingly large number of developers who insisted that it was impossible to use CSS for nice-looking sites. The accusation was that CSS sites were all “boxy” and to get something nice-looking, you had to use table layouts.
It was pretty obvious even back then that they were just people who didn’t want to learn something new and they would not listen to anything pro-CSS at all. In fact, developers who insist LLMs are not useful for development remind me of them a lot.
Anyway, the CSS Zen Garden was released, and it seemed to shut everybody like that up overnight. It conclusively won the argument that CSS sites could look as good as table-based sites and could even do things the table-based sites couldn’t.
> Tailwind looks ugly, but there are no hidden abstractions or structures in the code
Verily, Tailwind is the assembly language of CSS. No structure, no semantics, no abstractions, only twiddling specific bits of visual representation.
To turn to it is to admit that your product lacks the structure and the design vision that allow to use some abstraction ("semantic classes"), and that all you can usually do is to patch some areas of it, disconnected from the rest, and unable to touch the rest (lest it goes down in flames). Assembly is definitely suitable for patching.
This is often the endgame of old large products that changed hands and directions many times, without much care.
This seems like a radical, unsupported conclusion to draw from a single frontend architecture decision.
Maybe there's an overwhelmingly positive case to be made for high-abstraction CSS with hidden structures. Outside those few select cases, we've known the tradeoffs for 25 years, and the added complexity is rarely worth it.
I enjoyed working with a semantically styled frontend project as recently as 2024. It also used a React component library, which helped insulate per-component styles, while sharing the common parts.
It has. It's called @apply. It works fine. The Tailwind author is wrong about recommending people to avoid @apply. The Tailwind community at large is mostly wrong about it too (except people that like and use @apply).
I don't know how anti-abstraction came to become popular, but if you like semantic classes you can still use Tailwind. (why use Tailwind? It has some nice defaults and a coherent design language)
The anti-abstraction crowd, that push for repeating the same boilerplate over and over again, honestly grinds my gears. Even assembly doesn't make writing boilerplate its ideology (it has macros, and actual subroutines)
The real divide isn’t separation of concerns or implicit vs explicit structure. It’s whether you have staff that wants to think about markup as a data format expressing domain entities and/or generalization of presentation concerns.
Most developers and organizations don’t want to and they don’t want to think why or what doing so would buy them. They will probably find the tailwind local maxima enabling that reasonably comfortable and may even repeat the familiar mantra as has been done here. It especially pairs well with unreflective product management, which is the most popular kind of product management.
> The CSS Zen Garden worked because everyone was using a single markup file.
CSS Zen Garden was a proof of concept built around a single markup file. But if you extend that concept to hundreds of dynamic pages and a well built CSS design system, that's where the real power of CSS shows.
> In real life, it doesn't really work.
In real life it works incredibly well, which is what CSS Zen Garden originally showed, and what we've proven by applying these concepts to Firefox.
> If anything is out of place in the markup, the properties may not apply as intended. Similarly, if the CSS doesn't account for DOM structures, then you need modify rules or add new ones.
When stylesheets are written with an understanding of the Cascade and specificity, this isn't the case at all.
I also dont think you can cleanly separate HTML and style. Technically you can separate them but doing so in practice just handicaps your design and ability to express things in HTML and CSS (Zen Garden prohibiting css 3+ in most cases).
People have this idea that they should be decoupled. You can do that if you really contort them. Naturally, they are coupled.
The structure of HTML puts constraints on the style. You have to know about the style when writing HTML, even in this Zen Garden project. You can't escape the style and HTML understanding each other. If you have a compelling reason to make a broad range of styles swappable then OK - but you are constraining the design space considerably and there is usually no reason for this complexity and reduction in expressiveness.
The document and the style depend on eachother. You see this with localization. You might need to change spacing or padding or breakpoints to accomodate different languages (text being different length in different languages).
This is why all UI paradigms tightly couple style and structure. QT, GTK, SwiftUI, Flutter, etc. Its the same with CSS/HTML except for people who delude themselves into thinking these were supposed to be loosely coupled.
I’d previously understood the relationship to be that the document could remain unchanged, whilst the style (including visual structure/layout) changed. The simplest canonical example is that you can change the font, and all the words and meaning remain unchanged.
> You see this with localization. You might need to change spacing or padding or breakpoints to accomodate different languages (text being different length in different languages).
This is a really intereting case. Strictly I’d say it was a different document, if the language has changed. Really good translations change idiom, which can change meaning, and words, at the level of ohraes, although the intent would be preserved.
But I’m nit-picking, being contrarian, or exploring the edges of your comment.
Today, many web documents are app GUIs. Each field is essentially the same “thing” regardless the languge of its label. And in that sense, these are the same document, and your point holds.
I still think that if you can keep the markup as minimal as possible (reduce the div nesting to just what’s require to mark up logical sections of the content), then you could make a good stab at Zen-gardening your design. It’s very hard to do, however.
The dream was that you could separate content from presentation and content could be adapted and reinterpreted by anyone using whatever tools they choose: User Agents that actually respected the users' vision, not the publishers'.
The posts above claiming design and content are inextricably linked are probably blessed with all the standard senses.
As usual it's a bunch of folks talking past each other. Style and content together is a nice simplification when you want to conform to a particular vision. Separation is a nice abstraction if you want to enable multiple views of the same content (like a pdf version or a colorblind version or a vision impaired version) without having to change/control the content.
Like most things in this space, different tradeoffs make one better than the other in different scenarios. Taking a hard stance of "one true way" is probably missing some imagination or experience.
Accessibility certainly requires a content-first approach, I agree with you there. If you view each part of an application solely in terms of what it looks like to a sighted user, it's easy to miss the subtleties of what the underlying structure ought to be.
But when you start layering on the presentation, you're still generally binding that presentation layer tightly to the current content. If you, for example, were to restructure the links in the Zen Garden footer for some reason, most of the styles would break because they're bound to the current structure of the content. The separation you talk about only exists in one direction.
By comparison, when I talk about separation and decoupling in terms of code, I mean that there is a single, explicit, and tight API that acts as a clear boundary between two units. By explicit, I mean that I've designed the units specifically so that they expose this API - this is almost exactly the opposite of what I should be doing with content and presentation, as you point out! By tight, I mean that the API is as minimal as I can make it - two units interacting via an API need to understand nothing of each other except that API, and that API is as small as possible.
None of that is happening when it comes to the interaction between content and presentation. The content is not explicit - I'm actively trying to write the content for the design, which precludes making it an explicit API surface. Nor is the content tight - again, I want to build the content without worrying about how I will layer the design on top, and I don't want to limit myself to just a small surface area here.
So to me, it makes sense to see the content and presentation as being coupled together, even if that coupling ideally goes in one direction only. And if two systems are coupled together, it makes sense to do that explicitly by co-locating those systems. Therefore, I tend to prefer systems like Tailwind that let me apply the presentation layer directly in the content layer. (In practice, I mostly prefer other tools that still let me write real CSS syntax, but Tailwind is pretty damn convenient a lot of the time.)
As an aside, talking about accessibility, I'd forgotten how inaccessible some of the Zen Garden designs are with their addition of extra content in the presentation layer alone.
Except HTML is already a presentational markup language. People lose track of this.
Consider: MathML has a presentational schema and a content schema. The whole point of presentational MathML is the intermingling of concerns. If you want interoperable data, you use content MathML.
Interoperability is a noble goal, but if you want HTML to do everything you're already barking up the wrong tree.
Couple them how you want, HTML+CSS+JS is the system we've got, and it has to render well on mobile, tablet, and desktop. "deluded" and "supposed to be" are just word barriers that get in the way of doing shit that works.
CSS imports create a dependency tree of stylesheets. You can't render anything until all of the styles are loaded and parsed. Imports create a blocking serial dependency.
Yes, not only this, but in my experience, several older browsers actually crash or freeze with too many @import statements in the CSS. While those browsers weren't necessarily a priority to support with modern styles, they styles they recieved still needed to be minimally accessible, so crashing the browser was a deal breaker.
On Chrome, Android, when I bring the menu up, and scroll to the bottom, the Newsletter menu item is cut off (I know it is there as I can see it on Firefox Android).
Traditionally, one example is software that supports theming. Site owners who wanted to customize the look of something without getting their hands too dirty writing a whole new theme may duplicate and heavily modify the CSS from an existing one.
For applications people spend a expected to spend a lot of time in, the user may even be able to select the theme.
But, things like CSS custom properties have eaten into some of the basic use cases like palette swaps, assuming they're supported in the default theme.
Absolutely. When I first started building websites in the early 2000s, I was building site networks, where individuals would want their own themable websites quickly spun up. They all used the same backend system and components, each with unique designs and custom stylesheets. This pattern is incredibly common, and a lot of themable website building platforms are built on it.
Don't know why this was downvoted, it is the only zen garden like example I've come across. Multiple completely transformative CSS themes for user selection, not just light/dark/colourisation of the same layout
And how all six people links are to LinkedIn, when most of them have websites. (Wouldn’t surprise me if some of the LinkedIn profiles were incorrect, but since you can no longer view anything on LinkedIn without having an account…)
I get the sentiment, but what if it was the difference between not getting the thoughts out there and being able to celebrate the fruits of their labor?
It's okay to exercise nuanced views (as well as choosing to say nothing.)
what if it was the difference between not getting the thoughts out there and being able to celebrate the fruits of their labor?
I'm sure I don't know what implausible hypothetical scenario to which this could refer.
The "difference" is that of spending five entire minutes proofreading the output. But this blog post, like the other 98%, is once more the tasteless fruit of very, very little labor. Whether you value it or not, whether you are even able to recognize it anymore, writing for an audience is a skill.
I (and probably GP) feel legitimate dismay when I read the output of someone who had an obvious opportunity to exercise good taste for the benefit of the people who actually take the time to read it.
The continued inconvenience to you of reading opinions like this is obviously extremely unfortunate.
Mostly, I have other, more important stuff going in my life. I did write a lot of this post myself, but used AI to flesh out some of the details because otherwise between my perfectionism and tendency to overthink blog posts, I would have never gotten around to publishing this.
If you think other things are more important than writing, why would you expect anyone to take the time to read it ?
It’s just not a very efficient strategy, it might work for some readers, but as the comments show it’s a big turn off for many. Where it says “There’s one honest footnote”, that’s really grating, like the other commenter I also stopped reading there.
That’s not necessary rational, it’s just that we are social creatures that are really sensitive to those kind of surface level cues in communication, to gauge credibility. I’m sure many authors today use LLM in brainstorming, research, ask it to steelman an argument etc and no readers complain because it doesn’t impact the authorial voice.
The problem then is with letting LLM ‘fleshing out the details’: you end up having the LLM’s style and words all over your text. You can’t really do that without your authorial voice loosing credibility. I think next time, you have to go over it and edit it and make it sound like you.
If you don’t want to that, the good news is that I think people will start to get less critical of sloppy writing, as long as it sounds human. So you could sound convincing while leaving some details raw and not have the LLM have a go at it.
My approach is more "ship fast, iterate later". Your criticism of AI slop is valid and I share it. I've manually re-written the post today, no more AI slop. Of course, that came with the opportunity cost of not spending time on 100 other projects competing for my attention. AI has enabled me to do a lot more with my limited resource of attention.
Did you read it or, if English isn’t your first language, have someone who writes English well read it? I’ve had a lot of useful feedback on stuff I’ve written that way.
The below is a selected copy of the blog post, unbelievable that it didn't get unslopped:
> [..] , and on a site like this one that matters more than architectural purity. [..] Nothing in it depends on a build step [..] That distinction is worth keeping in mind [..] What matters is [..]
I appreciate the feedback. I did use AI to help me put this post together quickly. I've gone through today and manually re-written it. No more AI slop.
I doubt most of us would like to complain about anything, but with so many people (ab)using AI for writing their blogposts, it feels that a lot of the Web has become _homogenous_ in terms of style, and it's unfortunate.
Oh yeah. The fucking CSS Zen Garden. It started the trend that led to utter degradation of any usability in modern web interfaces. The idea was to make HTML decoupled from presentation, but the feeble CSS of that time could not express any real layouts.
So very quickly web designers started to just hard-code pixel widths into the CSS, removing any dynamic sizing.
For example, on this very page: https://csszengarden.com/ the two-column layout is done by using two overlapping DIVs with a padding on the left one. You could do 3 columns by using the same trick with left padding.
Want to do four columns? Tough. You'd better redesign your whole HTML for that to work. Or just hardcode the sizes.
Of course, this quickly led to interfaces where buttons have text that is cut off. But with lots and lots of useless whitespace padding around them.
Your frustrations with the state of CSS 2.0 at the time were quite common, and part of what CSS Zen Garden aimed to inspire people to transcend. Now, CSS has evolved to the point where none of these hacks are necessary. You can now write pure, semantic HTML, and pure CSS, and implement full-fidelity designs that work across all modern browsers. That was the whole dream of the CSS Zen Garden, which wasn't fully realized at the time, but now it is.
That's the issue. The CSS pushers did not have any ways of solving the CSS issues.
All that "inspiration" resulted in a loss of scalable interfaces and a switch to hard-coded element dimensions. And this persisted for a LONG time because Web UI designers are, in general, bad and were fine with flashy UI that is finger-breakingly bad.
Heck, it's _still_ a problem because people are by now completely oblivious to that. The art of automatic UI layout has been lost completely.
Umm... this is disingenuous. At the time, most websites were built using tables and were completely non-accessible. One of the reasons we moved to XHTML, semantic markup, CSS instead of Tables... was to enable accessibility.
No, it's not disingenious. Tables _were_ accessible and easily navigable, including by screen readers. They are also a very logical way of organizing content.
> One of the reasons we moved to XHTML, semantic markup, CSS instead of Tables... was to enable accessibility.
Again, nope. Try a design with 3-4 columns with the old CSS and see how it behaves. The order of elements in the HTML often differs from the visual order, confusing the readers.
It also breaks tab-navigation, even the https://csszengarden.com/ has the "View All Designs" button that is inaccessible.
Then add absolutely-positioned headers and other popular CSS patterns.
Author here. Like a lot of people on HN, Dave Shea's CSS Zen Garden is how I learned CSS in the first place. Building stylesheets for that one HTML file taught me to think about CSS as a system, and it stuck. Nearly two decades later I got to build the design system for the new Firefox.com together with a team from Lincoln Loop, on a contract engagement with Mozilla using pure, modern CSS with no preprocessors (almost). In the end, we did run a few things through preprocessors for performance reasons, but the site's CSS is fully authored in pure CSS syntax.
Happy to answer questions about the layered CSS, the legacy browser fallback, how the tokens got exported from design files, or anything else you're curious about.
I too was strongly inspired by the ideas that CSS Zen Garden was promoting, even if little to none of the real world work looked or worked like that.
Always weird to see what posts really bring out the negativity on HN, but pay that no mind. Some people can't stand others being happy (and some are just having a bad day...)
Be proud of what you accomplished and it must feel great to have contributed to something like Firefox!
Thanks for your kind words. Luckily, I thrive on criticism of my work, and don't take negativity personally. Working with the team at Mozilla on this truly felt really great!
CSS Zen Garden in the era of agentic software development.... I would say we're at a point where if the entire site was developed in tables or CSS or a Rust based engine emitting wasm positioned elements - no one would care anymore.
Just give me a view and let me operate on things. We're going to have our "LCARS" moment soon. Where no one really needs to create a UI - the system creates one for you at time of use - based on what you're looking at and doing. We're no longer going to need UI/UX, everything will adapt to the person using things.
You're partially correct, in the sense that agentic software development means that exact tech stack choices no longer restrict what's possible or easy to quickly achieve. But having well designed technologies and design systems is actually more important than ever, because AI agents can use those systems to build UIs on the fly more efficiently, with less tokens, and achieving more consistency and reliability. If you want to build an AI system that creates UI for you on the fly, an essential component is a good design system. Take a look at how Claude Design works: if you want to create a design there, one of the first things it encourages you to do is to build a design system, and underneath, that feature has been programmed to use specific frameworks that are also carefully designed and built to make agentic software development more efficient.
People say stuff like this and just... do you never think about accessibility? Have you never experienced stuff changing the UI under your feet and how incredibly annoying and flow-breaking it is?
It reminds me of people wanting Hollywood UIs that would obviously suck to actually use. Just completely ignoring the reality of using what you are suggesting.
A generative AI UI would be far better at accessibility than various fixed human attempts, because every user would be able to customise it to suit their own needs from their own set of customisation preferences.
People still aren't understanding that the mid-game of AI is the end of fixed cultural objects.
Everything becomes potentially customisable by the user, including the affordances, the UI, and the content algorithms.
People with AI Delusion Syndrome don’t really concern themselves with reality or other people. They’ve literally lost the plot in life under a grand delusion of corporate bootlicking.
The site is still live https://www.csszengarden.com, design selection here https://www.csszengarden.com/pages/alldesigns/ :).
Dave's old portfolio/blog is gone though: http://www.mezzoblue.com
The Bright Creative site is also AWOL.
Too bad neither is set up to redirect to the current https://daveshea.com/
Hope he's doing well. Guys like him, Doug Bowman, Jeffrey Zeldman... all a huge influence on teenaged-me hacking away on my little blog and thinking of going to SXSW someday.
EDIT: He's just left after being at Shopify for six years: https://lnkd.in/p/dcYBvQfq
Yes! Thank you. I linked to the site from my post as well. This is a great resource for anyone currently learning CSS.
This was the site shown to me to prove the separation of style and content. After that it was CSS-Tricks that I found myself frequently reading for answers to the things I was stuck on getting the layout to work.
> There’s one honest footnote.
nails on a chalkboard. when will agents stop writing like this
I can't wait for AI watermark checks to be widely available to stop such guessworks and the resulting ridicule. I'm not saying you're wrong, your guess could be.
Yeah, especially since we're exposed to so much AI-generated text these days, we may inadvertently pick up some verbal habits from it, the same way people tend to imitate each other. And needless to say false positives can be quite damaging here.
Pangram seems to be very accurate. I don't think that's a good thing though. Right now there is a lot of prejudice against AI users, and detection will only encourage that.
> Right now there is a lot of prejudice against AI users, and detection will only encourage that.
That’s exactly how it should be. If you serve me up AI-generated rubbish that I’m then supposed to sift through, you’ve earned the ridicule of the whole world.
> AI-generated rubbish
Implies you'd accept it if it wasn't rubbish. Seriously doubt your filter is based on quality.
> you’ve earned the ridicule of the whole world
As if human writing immunizes you from that. Published an article about garbage collection and had people complain about my human voice. One went so far as to suggest I had mental issues. I received praise too but some things you just never forget.
Best part is Claude warned me repeteadly that I should tone it down, and I deliberarely ignored it in order to preserve my voice and keep it pure. I'm much more inclined to listen now.
If its substantially AI generated then it's definitionally rubbish, even if it was a good answer to the prompt. I can send a prompt myself, don't waste my time republishing AI answers.
Please define "substantially". Exactly how many words must come from my hands and brain in order for a work to qualify as human?
Imagine that I write an article manually and keep it to myself. Then I prompt my favorite AI model and it somehow generates the exact same article, against all odds, despite having never seen it before. Then I publish the AI's article, which is equal to mine. Is the article rubbish?
> I can send a prompt myself, don't waste my time republished AI amswers.
I can do it too. I consider it rude to reply to people with AI answers during conversation. Not because I hate AI, but because it made the social interaction pointless.
That doesn't somehow invalidate the value of an AI generated article though. Not everyone thinks to prompt it with that exact idea. Not everyone has an AI they can prompt. Not everyone wants to waste their limited tokens on the idea.
I realize that reading Claudish can be aggravating but that doesn't somehow eliminate the ideas contained in the article. Those can still be very valuable, which is why I advocate for quality filters.
That's a little metaphysical for my taste. If its the same bytes of text, provenance is destroyed anyways, so who knows if the tree fell in the forest.
"Substantially" to me would mean not your ideas and not your writing. I'm sure there are borderline cases that are hard to decide but a rule of thumb for me would be if it takes more time to read than it took the "author" to write.
The issue is metaphysical. If AI can produce the exact same output a human would, does it matter who made it?
It's possible for the ideas to come from the author while the writing is outsourced to someone else. Ghostwriting is an established practice.
Effort involved in writing sounds a lot like the "sweat of of the brow" doctrine, which is rejected even by copyright monopolists.
It's about effort into thinking. If no effort went into either thinking or writing, then I'll plead guilty to sweat of the brow doctrine. Again, just send me the prompt and I'll feed it to AI myself.
Reading is about learning interesting new ideas, enjoying a narrative. The suffering of the author is beside the point.
I can sympathize with the notion that AI writing currently sucks, but not that it's automatically invalid or deserving of mockery. Maybe one day we'll have far better models. Maybe they'll do a good job without inserting any load-bearing vocabulary.
Asking for the prompts is fine, but might not be sufficient. The process iterative, and may incorporate data that won't be published. For example, I recently published a Sol/Fable benchmark article. It would be trivial for anyone to prompt a new version of the article if they had the raw benchmark data, but this data will never be published.
It's not about how good or bad the AI writing is. It's about the human interaction, if someone outsourced their thinking to AI then they are bullshitting me and I will rate their thoughts appropriately at the human level.
You can value human authorship without automatically ridiculing anyone using AI.
If someone's already burned the trees down to generate it once, why would you want to burn more trees, just so you can do it yourself? Do you hate the Earth or something?
I’ve never said that you don’t deserve to be ridiculed when you write human rubbish, but I haven’t claimed the opposite either. However, I do believe that you definitely and without exception deserve to be ridiculed when you produce AI-generated rubbish.
Analyze the game theory of what you just proposed. Have AI effortlessly generate an article for your idea, get ridiculed. Put a lot of time and effort into it instead, maybe get ridiculed anyway.
It's gonna be a no brainer for a lot of people.
Clearly it will make this even worse. Soon every HN posts will have some comments like "86% AI. Skip it."
Using slop constructs to convey intricacies about beautiful design is the purest form of anti-design.
I appreciate the feedback. I did use AI to help me put this post together quickly. I've gone through today and manually re-written it. No more AI slop.
That's where I stopped reading.
> “Then you tried to ship real client work, and the dream fell apart.”
For me it was here. I have tried for months to get AI to write for me and have now fully embraced the fact that LLMs are not ready to do that for me. None of them. I’ve gone back to writing my own content and only using the LLM to brainstorm.
Remember this detail for later.
This is really great work, but I think a lot of folks on HN don't look kindly on the CSS Zen Garden or that era of CSS. They think the markup/stylesheet separation of concerns was a terrible idea, an idea that Tailwind exists to fix. (I think they're wrong, that separation of concerns is good, Tailwind is a hack, and get off my lawn while you're at it.)
The point is - now the modern vanilla web platform really can support first-class CSS-styled app components, from design systems, in production. This is really cool!
HTML and CSS were originally designed as document-oriented languages for digital document display; think MS Word or PDF with cross-document hyperlinks, and not an app SDK. The idea was simply "style your web site's titles, headings, paragraphs, footers, etc. in just one place; change it there and the whole site will update". That's the dream that CSS Zen Garden was meant to showcase. Interactivity and web apps came later, and CSS has taken a very long time to catch up.
But catch up it has, and I'll be glad when frontend web development sheds Tailwind and React in favor of the updated vanilla web platform; and I won't complain if we use super light web component libraries like Lit[0]).
[0] https://lit.dev
I agree completely. Personally, Tailwind never really resonated with me, though I've used it several times, and we did even briefly consider it for this project. I always felt that it was an approach created by people who never understood the paradigm of CSS, and didn't want to. Since my career started with CSS, I've always been more of a purist.
I think a collection of basic utility classes (w-100, m-2-t) and layout components (<Flex dir="row" gap="2">, etc.) are equivalent ideas, and they are nice for quickly setting up a one-off layout that's very readable. But Tailwind turns this practical idea into a religion that locks projects in to using it and harms readability.
Human readability is a very useful proxy for good modularity and separation of concerns (and modularity increases scalability and reusability). Since LLMs take the whole thing in at once, they are terrible at module boundaries. (They also suck at theory of mind, and their comments reflect it, but I digress.)
I see no connection whatsoever with the CSS Zen Garden dream. CSS Zen Garden was about applying radically different styles to the same markup. This is about newer CSS features like Custom Properties, Flex and Grid making maintenance of a single stylesheet for a single completely typical website.
This is a reasonable reaction. Thank you for pointing that out. I've updated the post with some thoughts on this. Basically, think the radically different styles part of the CSS Zen Garden was only how the dream was shown, but it wasn't the substance of the dream itself. The substance of the dream was to show the power of CSS, and what was possible with separation of concerns and browser support. And that's what I think we showed with what we build for Firefox.
Do they have the design system open source somewhere?
Yes, you'll find it in this repo: https://github.com/mozmeao/springfield
Search for "flare" if you're looking for the CSS.
Considering the post ends with a link to the author's consultancy page, I'm guessing not.
If your team is rethinking its front-end foundation, get in touch.
I still remember being like 15 years old and seeing my website(s) land on CSS Zen Garden, CSS Thesis, etc... using Mint analytics (throwback! shoutout to @shauninman) to see all the inbound traffic. What a time to be alive.
The current firefox.com is incredibly simple, though. It's also pretty tablet/phone centric (everything is so large on Desktop).
Personally, I love the current Firefox.com design and see the simplicity as a feature. And it's designed to be responsive to any screen size. A design like this would have been incredibly challenging to build with CSS 2.0 in 2008. That's the point of this post. But if you find the design boring, just like the CSS Zen Garden, you can design your own user stylesheet to re-style the whole site, hundreds of pages in dozens of languages, into any design you want, with one stylesheet, because the styles are cleanly separated from the markup. Have fun!
Yeah... I was trying to figure out what he was pointing to, and was like.. oh, the Firefox website... went there and was pretty uninspired by the design, at least in desktop.
The CSS Zen Garden worked because everyone was using a single markup file. In real life, it doesn't really work.
Instead of thinking of separation of concerns as a religious principle, think about what benefits it actually yields in the case of HTML.
When the markup is completely separated from its styling, this means that the CSS rules need a way to be mapped onto the DOM. This involves specific elements, organized a specific way. If anything is out of place in the markup, the properties may not apply as intended. Similarly, if the CSS doesn't account for DOM structures, then you need modify rules or add new ones.
This way of mapping is an implicit structure. It's something extra that's required, beyond the source code that's there. It can be computed by the browser, but it's not explicitly stated for a developer looking at the code to understand.
Contrast this with Tailwind, Tachyons, etc., where nearly all the structure is explicit, less complex, discoverable, and out in the open.
Hidden structure looks nice to the developer. The code "looks" clean. But understanding a code base's implicit structure is ephemeral, and there's inherent technical debt that will need to be repaid later.
Tailwind looks ugly, but there are no hidden abstractions or structures in the code, beyond its easy conventions and a minimal config file.
And, yes, there are ways to make high-abstraction CSS work, say, with a component library of known DOM patterns. But at that point, why not build the styles into the components directly, a la Tailwind, instead of adding complexity?
> The CSS Zen Garden worked because everyone was using a single markup file. In real life, it doesn't really work
The dream of the CSS Zen Garden never really extended beyond itself. That wasn't the point. The point was to show people "look at all these pages that look nothing like each other: they're all the same HTML." That was the magic.
Keep in mind the context: you still largely needed structural HTML to effect the layout of your page. Almost everybody was building with HTML where the markup was critical to the appearance. Frontpage, Dreamweaver, and every other tool generated almost no CSS—or at least no good CSS.
This isn't my interpretation. From the site itself:
> There is a continuing need to show the power of CSS. The Zen Garden aims to excite, inspire, and encourage participation. ... CSS allows complete and total control over the style of a hypertext document. The only way this can be illustrated in a way that gets people excited is by demonstrating what it can truly be, once the reins are placed in the hands of those able to create beauty from structure.
More specifically – because I think this is an aspect that has mostly been lost to time – when the CSS Zen Garden was first created, table layouts were still the norm and there was huge pushback from a surprisingly large number of developers who insisted that it was impossible to use CSS for nice-looking sites. The accusation was that CSS sites were all “boxy” and to get something nice-looking, you had to use table layouts.
It was pretty obvious even back then that they were just people who didn’t want to learn something new and they would not listen to anything pro-CSS at all. In fact, developers who insist LLMs are not useful for development remind me of them a lot.
Anyway, the CSS Zen Garden was released, and it seemed to shut everybody like that up overnight. It conclusively won the argument that CSS sites could look as good as table-based sites and could even do things the table-based sites couldn’t.
> Tailwind looks ugly, but there are no hidden abstractions or structures in the code
Verily, Tailwind is the assembly language of CSS. No structure, no semantics, no abstractions, only twiddling specific bits of visual representation.
To turn to it is to admit that your product lacks the structure and the design vision that allow to use some abstraction ("semantic classes"), and that all you can usually do is to patch some areas of it, disconnected from the rest, and unable to touch the rest (lest it goes down in flames). Assembly is definitely suitable for patching.
This is often the endgame of old large products that changed hands and directions many times, without much care.
This seems like a radical, unsupported conclusion to draw from a single frontend architecture decision.
Maybe there's an overwhelmingly positive case to be made for high-abstraction CSS with hidden structures. Outside those few select cases, we've known the tradeoffs for 25 years, and the added complexity is rarely worth it.
A right abstraction adds simplicity.
I enjoyed working with a semantically styled frontend project as recently as 2024. It also used a React component library, which helped insulate per-component styles, while sharing the common parts.
> no abstractions,
It has. It's called @apply. It works fine. The Tailwind author is wrong about recommending people to avoid @apply. The Tailwind community at large is mostly wrong about it too (except people that like and use @apply).
I don't know how anti-abstraction came to become popular, but if you like semantic classes you can still use Tailwind. (why use Tailwind? It has some nice defaults and a coherent design language)
https://css-tricks.com/tailwinds-apply-feature-is-better-tha...
The anti-abstraction crowd, that push for repeating the same boilerplate over and over again, honestly grinds my gears. Even assembly doesn't make writing boilerplate its ideology (it has macros, and actual subroutines)
The real divide isn’t separation of concerns or implicit vs explicit structure. It’s whether you have staff that wants to think about markup as a data format expressing domain entities and/or generalization of presentation concerns.
Most developers and organizations don’t want to and they don’t want to think why or what doing so would buy them. They will probably find the tailwind local maxima enabling that reasonably comfortable and may even repeat the familiar mantra as has been done here. It especially pairs well with unreflective product management, which is the most popular kind of product management.
> The CSS Zen Garden worked because everyone was using a single markup file.
CSS Zen Garden was a proof of concept built around a single markup file. But if you extend that concept to hundreds of dynamic pages and a well built CSS design system, that's where the real power of CSS shows.
> In real life, it doesn't really work.
In real life it works incredibly well, which is what CSS Zen Garden originally showed, and what we've proven by applying these concepts to Firefox.
> If anything is out of place in the markup, the properties may not apply as intended. Similarly, if the CSS doesn't account for DOM structures, then you need modify rules or add new ones.
When stylesheets are written with an understanding of the Cascade and specificity, this isn't the case at all.
I also dont think you can cleanly separate HTML and style. Technically you can separate them but doing so in practice just handicaps your design and ability to express things in HTML and CSS (Zen Garden prohibiting css 3+ in most cases).
People have this idea that they should be decoupled. You can do that if you really contort them. Naturally, they are coupled.
The structure of HTML puts constraints on the style. You have to know about the style when writing HTML, even in this Zen Garden project. You can't escape the style and HTML understanding each other. If you have a compelling reason to make a broad range of styles swappable then OK - but you are constraining the design space considerably and there is usually no reason for this complexity and reduction in expressiveness.
The document and the style depend on eachother. You see this with localization. You might need to change spacing or padding or breakpoints to accomodate different languages (text being different length in different languages).
This is why all UI paradigms tightly couple style and structure. QT, GTK, SwiftUI, Flutter, etc. Its the same with CSS/HTML except for people who delude themselves into thinking these were supposed to be loosely coupled.
> The document and the style depend on eachother.
I’d previously understood the relationship to be that the document could remain unchanged, whilst the style (including visual structure/layout) changed. The simplest canonical example is that you can change the font, and all the words and meaning remain unchanged.
> You see this with localization. You might need to change spacing or padding or breakpoints to accomodate different languages (text being different length in different languages).
This is a really intereting case. Strictly I’d say it was a different document, if the language has changed. Really good translations change idiom, which can change meaning, and words, at the level of ohraes, although the intent would be preserved.
But I’m nit-picking, being contrarian, or exploring the edges of your comment.
Today, many web documents are app GUIs. Each field is essentially the same “thing” regardless the languge of its label. And in that sense, these are the same document, and your point holds.
I still think that if you can keep the markup as minimal as possible (reduce the div nesting to just what’s require to mark up logical sections of the content), then you could make a good stab at Zen-gardening your design. It’s very hard to do, however.
The dream was that you could separate content from presentation and content could be adapted and reinterpreted by anyone using whatever tools they choose: User Agents that actually respected the users' vision, not the publishers'.
And accessibility.
The posts above claiming design and content are inextricably linked are probably blessed with all the standard senses.
As usual it's a bunch of folks talking past each other. Style and content together is a nice simplification when you want to conform to a particular vision. Separation is a nice abstraction if you want to enable multiple views of the same content (like a pdf version or a colorblind version or a vision impaired version) without having to change/control the content.
Like most things in this space, different tradeoffs make one better than the other in different scenarios. Taking a hard stance of "one true way" is probably missing some imagination or experience.
I think that's an original issue though.
Accessibility certainly requires a content-first approach, I agree with you there. If you view each part of an application solely in terms of what it looks like to a sighted user, it's easy to miss the subtleties of what the underlying structure ought to be.
But when you start layering on the presentation, you're still generally binding that presentation layer tightly to the current content. If you, for example, were to restructure the links in the Zen Garden footer for some reason, most of the styles would break because they're bound to the current structure of the content. The separation you talk about only exists in one direction.
By comparison, when I talk about separation and decoupling in terms of code, I mean that there is a single, explicit, and tight API that acts as a clear boundary between two units. By explicit, I mean that I've designed the units specifically so that they expose this API - this is almost exactly the opposite of what I should be doing with content and presentation, as you point out! By tight, I mean that the API is as minimal as I can make it - two units interacting via an API need to understand nothing of each other except that API, and that API is as small as possible.
None of that is happening when it comes to the interaction between content and presentation. The content is not explicit - I'm actively trying to write the content for the design, which precludes making it an explicit API surface. Nor is the content tight - again, I want to build the content without worrying about how I will layer the design on top, and I don't want to limit myself to just a small surface area here.
So to me, it makes sense to see the content and presentation as being coupled together, even if that coupling ideally goes in one direction only. And if two systems are coupled together, it makes sense to do that explicitly by co-locating those systems. Therefore, I tend to prefer systems like Tailwind that let me apply the presentation layer directly in the content layer. (In practice, I mostly prefer other tools that still let me write real CSS syntax, but Tailwind is pretty damn convenient a lot of the time.)
As an aside, talking about accessibility, I'd forgotten how inaccessible some of the Zen Garden designs are with their addition of extra content in the presentation layer alone.
Except HTML is already a presentational markup language. People lose track of this.
Consider: MathML has a presentational schema and a content schema. The whole point of presentational MathML is the intermingling of concerns. If you want interoperable data, you use content MathML.
Interoperability is a noble goal, but if you want HTML to do everything you're already barking up the wrong tree.
>The dream was that you could separate content from presentation and content
Yeah. And you cant effectively do that.
Even this project proves it. You have to know which CSS features never to use. You know, like CSS3, which started in 1998.
Couple them how you want, HTML+CSS+JS is the system we've got, and it has to render well on mobile, tablet, and desktop. "deluded" and "supposed to be" are just word barriers that get in the way of doing shit that works.
The postprocessor remains to fix some performance issue with @import? How does inlining imports fixes it? When I loaded the page, the font flickered.
Perhaps the article isn't about font import, those better be in html headers or simply stick to system fonts.
CSS imports create a dependency tree of stylesheets. You can't render anything until all of the styles are loaded and parsed. Imports create a blocking serial dependency.
Yes, not only this, but in my experience, several older browsers actually crash or freeze with too many @import statements in the CSS. While those browsers weren't necessarily a priority to support with modern styles, they styles they recieved still needed to be minimally accessible, so crashing the browser was a deal breaker.
On Chrome, Android, when I bring the menu up, and scroll to the bottom, the Newsletter menu item is cut off (I know it is there as I can see it on Firefox Android).
Contributions are welcome :) https://github.com/mozmeao/springfield
good good but are there really websites with 2 or more variously different designs for the same content, like Zen Garden did?
Traditionally, one example is software that supports theming. Site owners who wanted to customize the look of something without getting their hands too dirty writing a whole new theme may duplicate and heavily modify the CSS from an existing one.
For applications people spend a expected to spend a lot of time in, the user may even be able to select the theme.
But, things like CSS custom properties have eaten into some of the basic use cases like palette swaps, assuming they're supported in the default theme.
Absolutely. When I first started building websites in the early 2000s, I was building site networks, where individuals would want their own themable websites quickly spun up. They all used the same backend system and components, each with unique designs and custom stylesheets. This pattern is incredibly common, and a lot of themable website building platforms are built on it.
Light theme and dark theme?
I'd say mobile and desktop (from same html) would be more like css zen garden, than light/dark.
Those are palette variations, not enough Zengarden-like
For some reason this is a thing on almost every private torrent tracker
Don't know why this was downvoted, it is the only zen garden like example I've come across. Multiple completely transformative CSS themes for user selection, not just light/dark/colourisation of the same layout
> There’s one honest footnote.
I'm so tired of AI writing
It's a pity. Spending so much time to ship the CSS dream (clean, well-thought-out) and then using AI-talk to share it with the world.
I used AI to get the post out quickly, but I've gone through and manually re-written it today.
And the entire analogy is incoherent.
And how all six people links are to LinkedIn, when most of them have websites. (Wouldn’t surprise me if some of the LinkedIn profiles were incorrect, but since you can no longer view anything on LinkedIn without having an account…)
I get the sentiment, but what if it was the difference between not getting the thoughts out there and being able to celebrate the fruits of their labor?
It's okay to exercise nuanced views (as well as choosing to say nothing.)
The "difference" is that of spending five entire minutes proofreading the output. But this blog post, like the other 98%, is once more the tasteless fruit of very, very little labor. Whether you value it or not, whether you are even able to recognize it anymore, writing for an audience is a skill.
I (and probably GP) feel legitimate dismay when I read the output of someone who had an obvious opportunity to exercise good taste for the benefit of the people who actually take the time to read it.
The continued inconvenience to you of reading opinions like this is obviously extremely unfortunate.
Maybe they ARE lazy. Maybe they are unapologetically bullish on AI AND they did it just to spite the haters.
But it’s also possible that they have other, more important stuff going on in their life? Or that they find writing legitimately difficult?
I’m not excusing anything, or saying that you can’t feel dismay or even sickened.
I was merely proposing another perspective, that’s all.
Mostly, I have other, more important stuff going in my life. I did write a lot of this post myself, but used AI to flesh out some of the details because otherwise between my perfectionism and tendency to overthink blog posts, I would have never gotten around to publishing this.
If you think other things are more important than writing, why would you expect anyone to take the time to read it ?
It’s just not a very efficient strategy, it might work for some readers, but as the comments show it’s a big turn off for many. Where it says “There’s one honest footnote”, that’s really grating, like the other commenter I also stopped reading there.
That’s not necessary rational, it’s just that we are social creatures that are really sensitive to those kind of surface level cues in communication, to gauge credibility. I’m sure many authors today use LLM in brainstorming, research, ask it to steelman an argument etc and no readers complain because it doesn’t impact the authorial voice.
The problem then is with letting LLM ‘fleshing out the details’: you end up having the LLM’s style and words all over your text. You can’t really do that without your authorial voice loosing credibility. I think next time, you have to go over it and edit it and make it sound like you.
If you don’t want to that, the good news is that I think people will start to get less critical of sloppy writing, as long as it sounds human. So you could sound convincing while leaving some details raw and not have the LLM have a go at it.
My approach is more "ship fast, iterate later". Your criticism of AI slop is valid and I share it. I've manually re-written the post today, no more AI slop. Of course, that came with the opportunity cost of not spending time on 100 other projects competing for my attention. AI has enabled me to do a lot more with my limited resource of attention.
Did you read it or, if English isn’t your first language, have someone who writes English well read it? I’ve had a lot of useful feedback on stuff I’ve written that way.
The below is a selected copy of the blog post, unbelievable that it didn't get unslopped:
> [..] , and on a site like this one that matters more than architectural purity. [..] Nothing in it depends on a build step [..] That distinction is worth keeping in mind [..] What matters is [..]
I've unslopped it now. Thanks for the feedback.
AI loves an adverb. Even the title feels AI to me.
"Honest" is not an adverb though? It's an adjective, the adverb would be "honestly".
I appreciate the feedback. I did use AI to help me put this post together quickly. I've gone through today and manually re-written it. No more AI slop.
I'm so tired of the complaining about AI writing.
I doubt most of us would like to complain about anything, but with so many people (ab)using AI for writing their blogposts, it feels that a lot of the Web has become _homogenous_ in terms of style, and it's unfortunate.
Lol beat me to it
Came here to say the same. I closed the window on the spot. I don't even care if I miss out on something.
I don't think these people realize how much damage they are doing to their reputations.
Oh yeah. The fucking CSS Zen Garden. It started the trend that led to utter degradation of any usability in modern web interfaces. The idea was to make HTML decoupled from presentation, but the feeble CSS of that time could not express any real layouts.
So very quickly web designers started to just hard-code pixel widths into the CSS, removing any dynamic sizing.
For example, on this very page: https://csszengarden.com/ the two-column layout is done by using two overlapping DIVs with a padding on the left one. You could do 3 columns by using the same trick with left padding.
Want to do four columns? Tough. You'd better redesign your whole HTML for that to work. Or just hardcode the sizes.
Of course, this quickly led to interfaces where buttons have text that is cut off. But with lots and lots of useless whitespace padding around them.
Your frustrations with the state of CSS 2.0 at the time were quite common, and part of what CSS Zen Garden aimed to inspire people to transcend. Now, CSS has evolved to the point where none of these hacks are necessary. You can now write pure, semantic HTML, and pure CSS, and implement full-fidelity designs that work across all modern browsers. That was the whole dream of the CSS Zen Garden, which wasn't fully realized at the time, but now it is.
That's the issue. The CSS pushers did not have any ways of solving the CSS issues.
All that "inspiration" resulted in a loss of scalable interfaces and a switch to hard-coded element dimensions. And this persisted for a LONG time because Web UI designers are, in general, bad and were fine with flashy UI that is finger-breakingly bad.
Heck, it's _still_ a problem because people are by now completely oblivious to that. The art of automatic UI layout has been lost completely.
Umm... this is disingenuous. At the time, most websites were built using tables and were completely non-accessible. One of the reasons we moved to XHTML, semantic markup, CSS instead of Tables... was to enable accessibility.
No, it's not disingenious. Tables _were_ accessible and easily navigable, including by screen readers. They are also a very logical way of organizing content.
> One of the reasons we moved to XHTML, semantic markup, CSS instead of Tables... was to enable accessibility.
Again, nope. Try a design with 3-4 columns with the old CSS and see how it behaves. The order of elements in the HTML often differs from the visual order, confusing the readers.
It also breaks tab-navigation, even the https://csszengarden.com/ has the "View All Designs" button that is inaccessible.
Then add absolutely-positioned headers and other popular CSS patterns.
I remember tables within tables within tables. Were those really accessible? The humans writing that html couldn't always keep it straight
Yes? What's problematic with nested tables? You just tab in and out of them.
Now try to navigate something like the WSJ/NYTimes home page.
If you remember the old days of good UI, there was this idea of "tab groups".
tables are a very logical way of organizing _tabular_ content. they're a terrible tool for layout, accessibility wise
No, they're not. They are _perfect_ for layouts, as they naturally support "move left/move right/up/down" directions.
To this day, this is STILL not working well for DIV-based designs.
Author here. Like a lot of people on HN, Dave Shea's CSS Zen Garden is how I learned CSS in the first place. Building stylesheets for that one HTML file taught me to think about CSS as a system, and it stuck. Nearly two decades later I got to build the design system for the new Firefox.com together with a team from Lincoln Loop, on a contract engagement with Mozilla using pure, modern CSS with no preprocessors (almost). In the end, we did run a few things through preprocessors for performance reasons, but the site's CSS is fully authored in pure CSS syntax.
Happy to answer questions about the layered CSS, the legacy browser fallback, how the tokens got exported from design files, or anything else you're curious about.
I too was strongly inspired by the ideas that CSS Zen Garden was promoting, even if little to none of the real world work looked or worked like that.
Always weird to see what posts really bring out the negativity on HN, but pay that no mind. Some people can't stand others being happy (and some are just having a bad day...)
Be proud of what you accomplished and it must feel great to have contributed to something like Firefox!
Thanks for your kind words. Luckily, I thrive on criticism of my work, and don't take negativity personally. Working with the team at Mozilla on this truly felt really great!
Is the code open source? It‘s not part of the protocol design system?
Correct, it's not part of Protocol. It's in this repo: https://github.com/mozmeao/springfield
[flagged]
[dead]
I tried some of the examples. The UX for seeing the different designs is terrible.
1. Go to site
2. Visually scan the page for the style controls
3. Click one
4. Everything changes
5. Visually scan the page for the style controls etc.
I dont want to visually scan every time I change the stlye.
https://csszengarden.com/216/
https://www.csszengarden.com/pages/alldesigns/
That non-CSS swappable layout is much better
CSS Zen Garden in the era of agentic software development.... I would say we're at a point where if the entire site was developed in tables or CSS or a Rust based engine emitting wasm positioned elements - no one would care anymore.
Just give me a view and let me operate on things. We're going to have our "LCARS" moment soon. Where no one really needs to create a UI - the system creates one for you at time of use - based on what you're looking at and doing. We're no longer going to need UI/UX, everything will adapt to the person using things.
You're partially correct, in the sense that agentic software development means that exact tech stack choices no longer restrict what's possible or easy to quickly achieve. But having well designed technologies and design systems is actually more important than ever, because AI agents can use those systems to build UIs on the fly more efficiently, with less tokens, and achieving more consistency and reliability. If you want to build an AI system that creates UI for you on the fly, an essential component is a good design system. Take a look at how Claude Design works: if you want to create a design there, one of the first things it encourages you to do is to build a design system, and underneath, that feature has been programmed to use specific frameworks that are also carefully designed and built to make agentic software development more efficient.
People say stuff like this and just... do you never think about accessibility? Have you never experienced stuff changing the UI under your feet and how incredibly annoying and flow-breaking it is?
It reminds me of people wanting Hollywood UIs that would obviously suck to actually use. Just completely ignoring the reality of using what you are suggesting.
A generative AI UI would be far better at accessibility than various fixed human attempts, because every user would be able to customise it to suit their own needs from their own set of customisation preferences.
People still aren't understanding that the mid-game of AI is the end of fixed cultural objects.
Everything becomes potentially customisable by the user, including the affordances, the UI, and the content algorithms.
People with AI Delusion Syndrome don’t really concern themselves with reality or other people. They’ve literally lost the plot in life under a grand delusion of corporate bootlicking.
[dead]
You’re replying to a bot sadly.