EDJOの(デ)メリット

Every Declaration Just Once (以下EDJO)アプローチの最大のメリットはなんだろうかということについて考えていた。情報設計と重なるところがまるでないため、設計思想としては完全に成立しない。つまりCSSを設計することを放棄し、設計されたHTMLに対してスタイルを割り当てていく手法としてのみ存在しうる。このことがすなわちメリットなのではないだろうか。

CSSの限られた文法が情報設計に基づく複雑な構造の表現に適さないことは明白だ。OOCSSではHTMLとCSSを設計のもとに平等に扱っていたが、どうしてもCSSにおいては限界があり、複雑な命名規則やCSSプリプロセッサーの登場となったのではないかと思う。CSSプリプロセッサーの高機能化により実現可能になりつつあるが、それと同時に高度に抽象化された複雑さも氾濫しつつある。

EDJOにおいてはその書かれ方を見ればわかる通り、設計というものを放棄することになる。設計されたHTMLに対してスタイルを割り当てていくという作業にすべては集約されることになるだろう。CSSは単にHTMLへスタルを割り当てていくのみでそれ以上の意味は持たない。OOCSSにおいてはともすれば「貧弱さ」と表現されるCSS文法の単純さに似合った割り切りであると言えよう。

CSSでの設計の放棄とEDJOの採用には、いくつかの派生的なデメリットとメリットが含まれる。

CSSのわかりやすさ

論理的な単位で定義がまとまっていないため、定義そのものはわかっても、他と組み合わせた結果どうなるかまでは不透明で、わかりやすさに欠けるCSSになる。定義が上書きされることがまずないという点ではOOCSSのような論理的な単位で管理するよりも誤解をする可能性は減るが、全般的にはデメリットと言えるだろう。

このわかりやすさの欠如はデバッガビリティーというようなものにはあまり影響をあたえることはない。なぜならこのわかりにくさの欠如はCSSファイルを相手にして格闘することが不可能なことを意味するので、ブラウザーに内蔵されている開発者ツールという武器を必ず使うことになるからだ。そういう意味では開発者ツールとは相性が良いとも言えるだろう。

セレクター数

IE9以下にはよく忘れてよくハマるCSSファイルごとのセレクター数に限界があるという仕様がある。定義ごとにセレクターを割り当てていくという手法の都合上、その限界はかなり簡単に突破してしまう。普通にCSSを書く場合と比べると、おおまかに3から5倍程度にセレクター数が増えると見積もる必要がある。

OOCSS+CSSプリプロセッサーで書く場合と比べるならば遭遇しやすいというだけに過ぎないとも言えるが、現実的な問題ではある。運用でカバーすることは難しいので、必ずチェックすることと、機械的に処理することを徹底する必要はあるだろう。

オブジェクトの再構築

OOCSSで書いている時に避けて通れないのがオブジェクトの再構築だ。EDJOなオブジェクトの妄想という記事でも触れられているが、僕もこれは非常に大きいと考える。OOCSSのオブジェクトを再構築するのは非常にコストが高い。単にオブジェクトのスタイルの編集だけに留まらず、そのリネーム、新たなオブジェクトの設計、参照の書きかえ、と必要になる作業が非常に多い。

EDJOにおいてはセレクターの書き足し、必要ならルールセットの追加という2つのパターンで常に完了する。OOCSSにおけるオブジェクトのような参照の対象を、CSSの仕様(または実装)にまで遡るため、書きかえたくてもできないという方が適切かもしれない。

このことはオブジェクトの再構築を避けるためによく行うプロパティーの上書きをなくせるということでもある。それに伴ってほぼ上書きが不要になることからセレクターの詳細度への配慮が不要になることでもあり、CSSにおける制約からHTMLのクラス名に強い命名規則を強制しなくても良いということでもある。

差分

近年の開発において差分への意識は不可欠であるとも言える。確実なマージのためにはレビューが不可欠であり、適切なレビューのためには差分が明確であることがある程度要求される。

通常のCSSの書き方では、CSSへのルールセットのブロック単位での追加とHTMLへのクラスの追加が差分として表示されることになる。対してEDJOではCSSへの編集のみに集約されることだろう。

@@ -1,4 +1,5 @@
 .foo,
+.bar,
 .black-text {
   color: black;
 }

CSSにおける差分もこのような単純な行の追加の組み合わせだけになる。他の差分ブロックと混ざることもない。

設計の放棄と言っても、実際には情報設計が最初にあり、それを反映させたHTMLがある。EDJOでは情報設計を元にするのではなく、それを元にしたHTMLに対してアピアランスとしてスタイルを割り当てていくというわけだ。情報設計の元でHTMLとCSSを並列させる場合、両者をきれいに連携させるためには強力な命名規則か高機能なCSSプリプロセッサー、またはその両者が必要になってしまう。それをHTMLに完全にCSSを従属させることでシンプルでストレートで逆転することのない序列を強いることができるのがEDJOの良いところだろう。

反面、論理的な構造を持たないため、CSSファイル単体で完結しないという問題がある。機械的な生成ではない形でスタイル・ガイド(のようなもの)を作成し、それを基準にブラウザーの開発者ツールでデバッグするという形での開発でないと苦しいだろう。書き方の違いに慣れることも含め、ドラスティックに開発フローを変更する手法であると言える。