CSS設計において特に大切にしている思想をまとめてみた
Zennの投稿は初です。TAK(@tak_dcxi)です。
今回投稿するのは自分なりのCSS設計のメモ。ある程度の規模感のサイトでのCSS設計において、僕がいくつか大切にしている思想の中から特に重要だと思っているものをピックアップしてまとめてみた。
「ある程度の規模感」とは以下のようなイメージ。
- テンプレートの数（※サイトのページ総数ではない）が10枚以上
- ローンチ後もPDCAが定期的に行われ、その都度サイトの更新や改修が行われるようなWebサイト
- サイトの更新や改修は自分以外のスキルを定義しないコーダーやエンジニアによって行われる
最後の「スキルを定義しないコーダーやエンジニアによって更新や改修が行われる」というのがポイントで、つまりスキルに大きな幅がある、とりわけ未経験入社の方のようなマークアップの知識が乏しい方が更新する可能性があることを前提としている。場合によっては急遽量産で知識の乏しい人がプロジェクトにアサインされる可能性もある。そういったリスクも考慮している。
こういった思想は日に日に変わっていくけれどど、現在の自分のログとして書いてみる。
主に僕は以下のことに気をつけながらCSSを書いている。
これらに加えて他に大切にしていることを含めて説明していく。
コードが長くなっても気にしないメンタルを持つ
僕がWebデザイナーとして働き始めた頃は「一行でも一文字でもコードを短く書く」「重複のない簡潔でスッキリとしたコードを書く」ことが良いコードだと思っていた。記述を極限まで減らしたシンプルでスッキリしたコードは確かに「綺麗なコード」かもしれない。
ただ、そういった「綺麗なコード」を書くことは実装者のエゴでしかなく、その「綺麗なコード」を実現するためには保守性や拡張性、再利用性、そしてCSSの捨てやすさを犠牲にしかねない。
もちろん、「綺麗なコード」はローンチ時には良いコードかもしれない。ファイルの容量も少なくなり、公開時のパフォーマンス的にも優れているだろう。ただ、Webサイトはローンチして終わりではなく、むしろ始まりである。記述を極限まで減らしたシンプルでスッキリしたコードは一時的な最適化になりがちだ。幾度となく行われる更新や改修時の保守性を高めるためなら、いくつか同じ処理が繰り返すような記述になったとしても気にしないメンタルを持とう。
ローンチ後にコンテンツ量が増減しても大丈夫なように、コンポーネントの追加や変更や削除が行われても悪い影響が出ないようにあえて冗長にコードを書くことも大切である。
誰が見ても理解がしやすいようなコードを書く
特にclassの命名。極力class名は省略しない。btn→ボタンはわかりそうな気もするけど、conはコンテナなのかコンテンツなのか分からない。titleを「ttl」と書いてどんなメリットがあるのか？
このように書いた人以外が分からない、意味が汲み取れないような省略は避ける。省略していいものはnavやimgのようにHTMLで使われているようなワードだけに絞る。誰が読んでもわかりやすいclass名をつけるためにも、その要素が何を意図しているのかをコードを触れる人に伝えるためにも、class名が長くなることを気にしてはいけない。
あとはSassを使うとついついfunctionとかループとか使いたくなるけど、そういった複雑なスタイルの指定は他の人に読解力を強いることとなる。スタイル指定は誰が見ても分かるようにできる限り易しく、シンプルに書いた方が良い。
本当に使わないと面倒くさい時だけfunctionとかmixinとかextendとか使って、それらは必要最小限にする。5個程度ループするくらいならforとかwhileとか使わない。ネストが深くなれば可読性は落ちるのでネストは浅く保つ。&__ 記法はルールセットの煩雑化を招きやすく、可読性やメンテナンス性を損なう可能性が極めて高くなるので使わない。やむを得ず複雑なコードを書かなければいけない時はコメントを残しておく…など。
保守性を高めることを何よりも重要な課題とする
良いCSSの4原則は「予測しやすい」「再利用しやすい」「保守しやすい」「拡張しやすい」であるけれど、僕はとりわけ保守しやすいことが最も重要視すべき項目だと思っている。もちろん保守性を高めるだけなら極端な話全ての要素にidを振ってそれにスタイルを当てればいいんだけど、そういう話ではない。
4原則の中で保守性を最優先に考えて、保守性を大きく低下させる危険性があるなら他の再利用性などを妥協するということ。
保守性を高めるためにすぐできることはすべての要素にclassを振ってそれにスタイルをあてる。構造（HTML）とスタイリング（CSS）を切り離し、詳細度を均一化するだけでも保守性の向上に貢献するだろう。idセレクタは設計時に決めた限定的な利用（JSに利用する時とかWAI-ARIAで参照する時とかページ内リンクを実装する時とか）に留めて、タイプセレクタにはベースとなる平坦化以外の固有のスタイルを指定しない。liとかaとかdtとかはついついやりがちなので気をつけていきたい。
具体的な理由はこちらの投稿で説明しています。
無理な共通化は行わない
CSSの再利用性は4原則の一つであるため重要であることには変わりはないが、無理な共通化は影響範囲が把握しにくくなって改修の時に大きな影響を及ぼす可能性があることに留意したほうがよい。
CSSの共通化は良い意味でも悪い意味でも影響力が大きい。書いた本人なら影響範囲を把握できたとしても、他の影響範囲を把握できていない人が運用に携わった場合に「ここだけ変えたかったのに…！」と言わんばかりにガツガツよくわからない指定が増えていくことはよくあることである。
デザインの見た目が同じだからといってコードも共通化したほうがいいかはケースバイケース。共通化し過ぎると変更に弱くなるので、程よく分割していったほうが扱いやすくなるし、むしろ共通化を行わないことも一つの手である。
僕の経験則では、カードのようにあらゆる箇所で使い回されるものであっても、エレメントの数や装飾が多いコンポーネントは共通化に気をつけたほうがいい。逆にリストや段落ブロックやボタンのように、HTMLのセマンティクスと同じレベルまで粒度を下げたコンポーネントは再利用性が極めて高いだけでなく、改修時にクラスの付替えとスタイリングが楽だったりする。これもケースバイケースだろうけど…。
divやspanが増えることを気にしない
本当に不要なdivやspanは淘汰すべきではあるが、HTMLは情報構造に意味づけを主とする言語。レイアウトや装飾にも紐付いているので、コンポーネントそのものとコンポーネントを配置するレイアウトの要素で分けるなど、あえてdivとspanを増やして冗長にコーディングすることも大切である。
確かにdivを極限まで減らしてシンプルに書いた方がHTMLの見た目はすっきりだろう。しかし、要素を減らすことで減った要素が持っていたスタイリングのルールを残った要素に受け継ぐこととなり、要素それぞれが持つ責任が重くなる。それゆえ保守性や拡張性に影響が出るかもしれない。
意味のあるdivやspanなら積極的に使おう。要素の持つスタイリングの責任は分散しよう。何度も言うようだけれど将来の予期せぬ変更を意識した冗長なコードは保守性につながる。
むしろ、タグの数を一つでも減らしたいという理由で不安定で保守性や拡張性の低いスタイル指定をしてしまうことを避けるべきだ。
ちなみに偏見だけど、スクールやオンラインサロン上がりの方ほどdivを減らしてシンプルに実装することに拘っている気がする。
最初から最適化しようとしない
フォロワーの谷さんの著書から得た知見ではあるが、「rule of three」という考え方がある。たとえ共通化できそうだって思ったとしても3回目まではなにも考えずに重複を許して記述する。3回目の出現でようやく共通化に乗り出すというもの。
CSSを書く時、ついつい最初から頑張っていい感じに書こうとしてしまうけど、体感90％はリファクタリングする羽目になる。最適化はすべてのコーディングが完了してから行う。それまでは蕁麻疹が出ようとも最適化を我慢してCSSを書こう。
ゴールは誰が触っても問題が起きにくいCSS設計
つまるところCSS設計のゴールは冒頭でも述べたようにスキルを定義しない、つまりマークアップの知識が乏しい方が更新するような場合にも問題が起きにくい設計を行うことだと思う。
公開時のパフォーマンスを第一に考えるのならセレクタもコードもシンプルで短いほうがいいし、記述の少ないシンプルなコードを書いたほうがファイルサイズの削減にも繋がり、（チリツモレベルで僅かにかもしれないけれど）パフォーマンス的に良いことは確かだろう。パフォーマンスを蔑ろにしろとは言わない。むしろパフォーマンスを向上させることはユーザーに対して至極重要なUXデザインにあたると思っている。ただ、そういったシンプルで簡潔なコードよりも冗長に書いて保守性を求めた方が、長期的な目線でのパフォーマンス向上には繋がる。
残念ながらCSSというものはどんなに丁寧に構築しても運用していく毎に徐々に劣化して壊れていく。保守性が低く、更新者のスキルに幅がある場合にはそのスピードはより加速されるだろう。それはパフォーマンスの低下に繋がるし、運用コストの増加にも繋がるはずだ。
CSSは徐々に劣化して壊れていくという辛い現実を受け入れて、なるべく劣化を食い止めるようにどんどん保険をかけていく。それがある程度の規模でのCSS設計には必要だと思っている。
おわりに
冒頭の「ある程度の規模感」を元に自分なりに重要視している思想をまとめてみた。ただし、この考え方は冒頭にあるように「ある程度の規模感」を意識した場合で、案件の規模によって適切なCSS設計の考え方は異なる。
例えばローンチ後は更新や改修が見込まれないティザーサイトなどの案件であれば、ここで述べたことを実践したところでとりこし苦労にしかならないだろう。それこそ記述を極限まで減らしたシンプルでスッキリした「綺麗なコード」が最適だし、最悪ユーザビリティやアクセシビリティに影響しない程度であれば（ハンバーガーボタンをフォーカスの当たらないdivで作ったり、a要素のアウトラインを消したりしていなければ）、開発時のスピード重視で保守性拡張性ガン無視したコードでもいいかもしれない。
他のCSSを書く上で気をつけたほうが良い事柄は昨年リリースした僕のnoteで長文で説明しているので、是非よければこちらもお読みください。（宣伝）
Discussion