CSS Zen Gardenの夢が、Firefox.comでついに実現

このサイトはまだ公開されている https://www.csszengarden.com 、デザインの選択はこちら https://www.csszengarden.com/pages/alldesigns/ :)。

これは本当に素晴らしい仕事だが、HNの多くの人はCSS Zen Gardenやその時代のCSSを快く思っていないと思う。彼らはマークアップとスタイルシートの関心の分離はひどいアイデアで、Tailwindはそれを修正するために存在すると思っている。（私は彼らが間違っていると思う。関心の分離は良いことで、Tailwindはハックであり、ついでに言えば私の芝生から出て行け。）

要は、今やモダンなバニラのウェブプラットフォームは、デザインシステムからのファーストクラスのCSSスタイル付きアプリコンポーネントを本番環境で本当にサポートできるということだ。これは本当にクールだ！

HTMLとCSSはもともとデジタル文書表示のための文書指向言語として設計された。MS WordやPDFにクロスドキュメントのハイパーリンクを付けたようなもので、アプリSDKではない。アイデアは単純に「ウェブサイトのタイトル、見出し、段落、フッターなどを一箇所でスタイルし、そこを変更すればサイト全体が更新される」というものだった。それがCSS Zen Gardenが示そうとした夢だ。インタラクティブ性とウェブアプリは後から来て、CSSが追いつくのに非常に長い時間がかかった。

しかし追いついた。フロントエンドのウェブ開発がTailwindとReactを捨てて、更新されたバニラのウェブプラットフォームを採用するようになれば嬉しい。そしてLit[0]のような超軽量なウェブコンポーネントライブラリを使っても文句は言わない。

[0] https://lit.dev

CSS Zen Gardenの夢とは何の関係も見当たらない。CSS Zen Gardenは同じマークアップに根本的に異なるスタイルを適用することだった。これはCustom Properties、Flex、Gridといった新しいCSS機能によって、単一のごく普通のウェブサイトのための単一のスタイルシートのメンテナンスが可能になるという話だ。

デザインシステムはどこかでオープンソースになっているのだろうか？

現在のfirefox.comは信じられないほどシンプルだ。それにタブレット/フォン中心でもある（デスクトップではすべてが大きすぎる）。

CSS Zen Gardenが機能したのは、誰もが単一のマークアップファイルを使っていたからだ。現実世界では実際には機能しない。

関心の分離を宗教的原則として考えるのではなく、HTMLの場合に実際にどのような利益をもたらすかを考えよう。

マークアップがスタイリングから完全に分離されていると、CSSルールをDOMにマッピングする方法が必要になる。これには特定の要素が特定の方法で組織化されることが含まれる。マークアップのどこかが間違っていると、プロパティが意図通りに適用されないかもしれない。同様に、CSSがDOM構造を考慮していない場合、ルールを修正したり新しいものを追加したりする必要がある。

このマッピングの方法は暗黙の構造だ。それはそこにあるソースコードを超えて要求される余分なものだ。ブラウザによって計算できるが、コードを見る開発者にとって理解するために明示的に述べられているわけではない。

これに対してTailwind、Tachyonsなどでは、ほとんどすべての構造が明示的で、複雑さが少なく、発見可能で、オープンになっている。

隠れた構造は開発者にとっては見栄えが良い。コードは「きれいに見える」。しかしコードベースの暗黙の構造を理解するのは一時的で、後で返済する必要がある固有の技術的負債がある。

Tailwindは醜く見えるが、その簡単な規約と最小限の設定ファイル以外に、コードに隠れた抽象化や構造はない。

そして、はい、高抽象化CSSを機能させる方法はある。たとえば、既知のDOMパターンのコンポーネントライブラリを使うなど。しかしその時点で、なぜスタイルを構築しないのか […]

パフォーマンス問題を修正するためのポストプロセッサが@importに残っているのか？インポートをインライン化するとどう修正されるのか？ページをロードしたとき、フォントがちらついた。

おそらく記事はフォントインポートについてではないだろう。それらはHTMLヘッダーにあるべきか、単にシステムフォントに固執すべきだ。