不特定多数の人が更新する大規模サイトに必要な CSS 設計の思想
今話題（？）の CSS 設計のメモ。 この「ある程度の規模」というのは、肌感覚としてテンプレートの枚数( ≠ Webサイトのページ総数)が 20P〜50P くらいのイメージ。 また、コーディング完了後に自分以外の人間による断続的な更新が入るという前提。 そして一番重要なのは「更新する人のスキルは定義しない。」ということ。つまり HTML の知識が乏しい人が更新する可能性があることを前提とする。
きっと1ヶ月くらいすれば変わると思うけど、自分の思想のログとして残しておく。
今ぼくは以下のことに気をつけながら CSS を書いている。
- コードが長くなることを気にしない
- セレクタが長くなることを気にしない
- セマンティクスの実現の難しさを理解し、妥協する
- 再利用性より保守性
- 拡張しやすい設計
- 最初から最適化しようとしない
- ゴールは目先のパフォーマンス向上ではなく誰が触っても問題が起きにくい設計
ひとつずつ解説してみる。
コードが長くなることを気にしない
一時期、というかついこの間まで、ぼくは一行でもコードを短く書くことに一種の美学を感じていたと思う。 デザイナーさんが 1px にこだわる的なアレかもしれない。
ただ、そこにはぼくのエゴしかなく、コードを短くするために保守性、拡張性、再利用性などを犠牲にしかねないというデメリットが発生する可能性がある。
コードは短い方がいいのだけど、保守性を高めるためなどにいくつか同じ処理を繰り返すような記述になったとしても気にしない。
セレクタが長くなることを気にしない
これについては最近よく言われるので言及するまでもないかもしれないけど、セレクタは長くなっても気にしない。
基本セレクタは Class。ID は設計時に決めた限定的な利用に留め（JSに利用するときとかページ内リンクとかあえて詳細度を最強にしたい場合）、エレメントに直接指定することはいかなる場合でもしない。
li とか a とかは今でもやりがちなので気をつけたい。
これは詳細度を複雑化させないため。
あと、極力短縮しない。button を btn と書くのはまだなんとなくわかりそうなものだけど、content を ct とか、書いた人以外がイメージしにくくなる class 名は控える。
再利用性より保守性
保守性を高めることを何よりも重要な課題とする。 とはいいつつもまったく再利用性を無視するということではなく、プライオリティの問題で、保守性を高めるだけなら極端な話全ての要素に固有の ID を振るとかすればいいんだけど、そういうことではない。
再利用性も重要だけど、そのために保守性を大きく低下させる危険性があるなら、再利用性の方を妥協するということ。
個人的には以下のような優先順位で考えるようにしている
保守性 > 拡張性 >>> 再利用性
セマンティクスの実現の難しさを理解し、妥協する
これは多分偉い人に怒られると思うんだけど、セマンティクスなコードは、更新する人のスキルは定義しないある程度大きな規模のサイトでは個人的に非常に難しさを感じる。
あまりHTMLの知識が無い人の場合、「よくわからないけどとりあえずやっちゃう」ことが多く、「よくわからないけどブラウザで表示できてるし良し」となる。
一生懸命 HTML5 で文書構造を明確化すると、それがかえって厳しいルールとなり、そのルールを守るためにはある程度の知識が必要になる。
もし、知識に乏しい人が更新する場合には裏目に出ることがあるということを認識する。
同じ要素なのに別の組み方が散見されるコードよりも、セマンティクスを捨てて統一化した方がいいと思った。
なので、危なさそうな感じの人が更新する可能性がある場合には、基本的に div 組っぽくする。
figure とか使わない。リストは順序のあるリストであっても ul で組む、など。
「更新者の選択肢を絞れるところまで絞る」ことが目的。
でももちろん良くないと思うので、何かいいアイデアを持っている人がいたら教えてほしい。
拡張しやすい設計
ここが一番の肝。新しい職場でアドバイスをいただいた。 これは JavaScript などにも応用できると思う。
拡張のしやすさは保守性と共存させなくてはいけない。
そのための考え方は CSS ファイルを大きく2つに分類するということ。
コアファイルを作り、そしてページ一意の指定はそれぞれ CSS を作成し（ページファイル）、その中でユニークな指定を行う。
コアファイルについて
コアファイルには以下の指定を行う。 共通のパーツ（ヘッダーなどのテンプレート部分）、サイトのベース（font-familyとか）、mixin など。
ページファイルについて
カテゴリ一意の指定をコアファイルで記述せずに、このページファイルに記述する。 カテゴリ毎に一つのページファイルを作成し、これをひとつの Web サイトと捉え、例え別のカテゴリで同じ指定、似た指定があったとしても、共通化させない。
この考えかたで重要なのは、共通化させすぎないということ。 そうすることで更新の際の手間とリスクは増えるものの、影響範囲を理解せずに更新されても「ここだけ変えたかったのに…」みたいな事故が起きにくくなると思う。
でも正直めちゃくちゃめんどくさいので、自分が管理する Web サイトでは絶対やりたくない。
最初から最適化しようとしない
これは谷さんの本から得た知見。
割りと最初から頑張っていい感じに書こうとしすぎるけど、絶対にリファクタリングする羽目になる。 ここで重要な考え方の一つを紹介する。
rule of three
この考え方は、例え「これ共通化できそうだな」って思っても3回まではなにも考えずに記述する。 2回同じ記述を書くことになっても我慢して、3回目の出現でようやく共通化に乗り出す。
数字の例に出すと最初に「1」という数字があり、その後に「3」と続いたとする。 すると次は「5」かもしれないし「6」かもしれないし「9」かもしれない。 もしその次の数字が「5」なら「この文字の並びは前の数字に2を足していってるんだな」と、パターンが明確になる。
そういったフェーズになってから最適化を行うように心がける。
ゴールは目先のパフォーマンス向上ではなく誰が触っても問題が起きにくい設計
誤解を恐れずに言えば、パフォーマンスを向上させることはユーザーにとって最も（といっていいほどの）重要なUXデザインにあたると思っている。
ただ、ここまで読んでわかると思うけど、公開時のパフォーマンスを第一に考えるなら他にもやり方は沢山ある。 セレクタもコードもシンプルで短いほうがいい。
しかし、そういったシンプルさよりも保守性を求めた方が、長期的な目線でのパフォーマンス向上には繋がる。 CSS というのは時間の経過とともにびっくりするくらい簡単にどんどん壊れていく。これはもう逃れられない。
保守性が低く、更新者のスキルが乏しい場合にはそれがより加速される。 影響範囲が大きい指定について「ここだけ変えたかったのに..えいっ」とばかりにガツガツよくわからない指定が増えていくことは間違いない。 それはパフォーマンの低下に繋がるし、運用コストの増加にも繋がる。
それに「運用者」と連呼していたけど、急遽量産で知識の乏しい人がプロジェクトにアサインされる可能性もある。 その辺りのリスク管理を含めて考えてみた。
ただし、この考え方は冒頭にあるようにこの考え方は不特定多数の人が更新する場合で、ケースによって CSS 設計の考え方は異なる。
おまけ
最近は Web サイトを作るのに非常に多くのことを考えなくてはいけなくなってきた。
ぼくが完全なる無能な状態でこの業界に入った2年半前はもうちょっとシンプルだったと思うんだけど、前の職場に入ったタイミングくらいから Sass を始めとする CSS プリプロセッサーとそのコンパイル環境、スマートフォンの普及によるマルチデバイス対応、タスクランナーによる効率化、Jade を始めとするテンプレートエンジンによる HTML の複雑化など、どんどん難しくなっている感がある。
これらはぼくの仕事をとても楽に（そしてかっこよく）してくれたけど、それらの複雑化した制作体系による弊害を、更新する人に押し付けるのは間違っている。モダンじゃなくても。 更新する人にはシンプルで易しい方がいい。そしてそれが HTMLとCSS を保守することに大いに寄与する。