3 ms·

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

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?

nonethewiser 19d ago
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.
- fragmede 19d ago
  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.
- ForHackernews 19d ago
  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'.
  - collingreen 19d ago
    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.
    - MrJohz 19d ago
      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.
wwweston 19d ago
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.
nine_k 19d ago
> 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.
- vehemenz 19d ago
  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.
  - nine_k 19d ago
    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.
- nextaccountic 19d ago
  > 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-than-it-sounds/ 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)
bastawhiz 19d ago
> 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.
- JimDabell 19d ago
  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.
yosito 19d ago
> 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.

nonethewiser 19d ago

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.

fragmede 19d ago
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.
ForHackernews 19d ago
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'.
- collingreen 19d ago
  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.
  - MrJohz 19d ago
    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.

wwweston 19d ago

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.

nine_k 19d ago

> 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.

vehemenz 19d ago
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.
- nine_k 19d ago
  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.
nextaccountic 19d ago
> 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-than-it-sounds/ 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)

bastawhiz 19d ago

> 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.

JimDabell 19d ago
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.

yosito 19d ago

> 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.