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?
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.
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.
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 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.
This is really great work, but I think the author does himself a bit of a (regrettable) disservice, on HN at least, by referring to the Firefox.com rebuild in terms of the CSS Zen Garden... a lot of folks on HN don't look fondly back on 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, I still think Tailwind is a hack, and get off my lawn while you're at it.)
The point is - with updates that have arrived in the last few years, now the 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 Lit and the updated vanilla web platform.
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.
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…)
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 [..]
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.
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.
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?
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.
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.
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.
The site is still live https://www.csszengarden.com, design selection here https://www.csszengarden.com/pages/alldesigns/ :).
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.
This is really great work, but I think the author does himself a bit of a (regrettable) disservice, on HN at least, by referring to the Firefox.com rebuild in terms of the CSS Zen Garden... a lot of folks on HN don't look fondly back on 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, I still think Tailwind is a hack, and get off my lawn while you're at it.)
The point is - with updates that have arrived in the last few years, now the 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 Lit and the updated vanilla web platform.
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.
The current firefox.com is incredibly simple, though. It's also pretty tablet/phone centric (everything is so large on Desktop).
Do they have the design system open source somewhere?
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.
> There’s one honest footnote.
I'm so tired of AI writing
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…)
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 [..]
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.
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".
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.
Lol beat me to it
good good but are there really websites with 2 or more variously different designs for the same content, like Zen Garden did?
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.
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.
Is the code open source? It‘s not part of the protocol design system?
[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