CSS Zen Garden 的梦想终于成真
The CSS Zen Garden dream shipped
2008 年，CSS Zen Garden 曾让我瞥见纯 CSS 重构设计的梦想，但现实受限于浏览器差异和缺乏变量，我们不得不依赖服务器端处理和无数 Hack。如今，随着 Custom Properties、Grid 和 Flexbox 的成熟，这个梦想终于在 Firefox.com 的重建中实现。我与 Mozilla 及 Lincoln Loop 团队合作，完全使用现代原生 CSS 构建了包含 70 多个组件的设计系统，无需预处理器。虽然为了性能在生产环境保留了 PostCSS 处理 @import，但核心代码仍是浏览器直接理解的纯 CSS。这证明了平台已准备好，让设计师的决策能无损地直达生产环境。
工具每隔几年就会更换，但不变的价值在于：在一个系统中，做正确的事也是最容易的事，且设计师的决策无需经过三次转译就能直达生产环境。
HN 评论区
57- bpbp-mango
这里有一个诚实的脚注。
就像指甲刮黑板一样刺耳。代理们什么时候才能停止这样写作？
- kreetx
该网站仍然在线：https://www.csszengarden.com，设计选择在此：https://www.csszengarden.com/pages/alldesigns/ :)。
- vehemenz
CSS Zen Garden 之所以成功，是因为每个人都使用同一个标记文件。在现实生活中，这行不通。
与其将关注点分离视为一种宗教原则，不如思考它在 HTML 案例中实际带来了什么好处。
当标记与其样式完全分离时，这意味着 CSS 规则需要一种映射到 DOM 的方式。这涉及特定的元素，并以特定的方式组织。如果标记中有任何错位，属性可能无法按预期应用。同样，如果 CSS 没有考虑到 DOM 结构，你就需要修改规则或添加新规则。
这种映射方式是一种隐式结构。它是源代码之外所需的额外内容。浏览器可以计算它，但对于查看代码的开发者来说，它并没有明确说明，难以理解。
相比之下，在 Tailwind、Tachyons 等框架中，几乎所有结构都是显式的，更简单、更易发现、且公开透明。
隐藏的结构对开发者来说看起来很美好。代码“看起来”很干净。但理解代码库的隐式结构是短暂的，而且存在固有的技术债务，日后必须偿还。
Tailwind 看起来很丑，但除了其简单的约定和一个最小化配置文件外，代码中没有隐藏的抽象或结构。
当然，确实有办法让高抽象度的 CSS 发挥作用，例如使用已知 DOM 模式的组件库。但到了那一步，为什么不直接构建样式 […]
- TimTheTinker
这项工作真的很棒，但我认为 HN 上的很多人对 CSS Zen Garden 或那个时代的 CSS 并不看好。他们认为标记/样式表的关注点分离是个糟糕的主意，而 Tailwind 的存在正是为了解决这个问题。（我认为他们错了，关注点分离是好的，Tailwind 是个权宜之计，而且趁早滚出我的草坪。）
重点是——现在，现代的原生 Web 平台确实能够在一生产环境中支持来自设计系统的一等 CSS 样式化应用组件。这真的很酷！
HTML 和 CSS 最初是作为面向文档的语言设计的，用于数字文档显示；想想 MS Word 或带有跨文档超链接的 PDF，而不是应用 SDK。其理念很简单：“只需在一个地方设置你网站标题、页眉、段落、页脚等的样式；在那里更改，整个网站就会更新”。这正是 CSS Zen Garden 想要展示的愿景。交互性和 Web 应用是后来才出现的，而 CSS 花了很长时间才赶上来。
但它确实赶上了，我很高兴看到前端 Web 开发能抛弃 Tailwind 和 React，转而采用更新后的原生 Web 平台；如果我们使用像 Lit[0] 这样超轻量的 Web 组件库，我也不会抱怨。
[0] https://lit.dev
- chrismorgan
我完全看不出这与 CSS Zen Garden 的愿景有任何联系。CSS Zen Garden 的核心在于对相同的标记应用截然不同的样式。而这里讨论的是利用 Custom Properties、Flex 和 Grid 等更新的 CSS 特性，来维护单个典型网站的单一样式表。