BEM, OOCSS, SMACSS, FLOCSSなど先駆者が築き上げてきたcss設計を読んだけど、これから作ろうとしてるプロダクトにどれもしっくり来ないので独自のcss設計(命名規則)を作っちゃった
というお話です。
ディレクトリ構成
先代が作ったプロダクトにはFLOCSS×BEMが採用されていたので、ガラッと変えないようFLOCSSをベースにしています。
まずはFLOCSSのディレクトリ構造がこちら
css/
├ foundation/ ... デフォルトスタイルの初期化や、プロジェクトにおける基本的なスタイルなど
├ layout/ ... プロジェクト共通のコンテナーブロックのスタイル
└ object/ ... プロジェクトにおける繰り返されるビジュアルパターン
├ component/ ... 再利用できるパターンとして、小さな単位のモジュール
├ project/ ... プロジェクト固有のパターンであり、いくつかのComponentとそれに該当しない要素
└ utility/ ... わずかなスタイルの調整のための便利クラスなど
このまま採用してしまっても良かったのですが、componentとprojectどっちに属すか論争がたびたび行われていたので、もっと直感的でファイルを探しやすく、初心者にもやさしい設計を目指しました。
色々な試行錯誤の結果がこちら
css/
├ foundation/ ... resetやbaseなど土台となるcss
├ layout/ ... headerやfooterなど大枠となるcss
├ component/ ... 大小様々な粒度を持つコンポーネント用css
├ page/ ... そのページ内でしか使えないページ固有のcss
├ _utilities.css ... わずかなスタイルの調整のための便利クラスなど
├ _variables.css ... css内で使える変数
└ app.css ... cssのエントリーポイント
- foundation, layoutはそのまま
- objectを廃止して平坦に並べる。
- componentの粒度の幅を広げて一箇所に集約。ボタンからカレンダーまで全部ここ。
- projectは直感的にわかりづらかったので page に変更。ページ固有のcssとして置いておくことで、どうしてもこのページだけデザイン変えたい時に使えます。(最終手段)
- _utilities と _variables は見る頻度が多いのでファイル郡から見つけ出しやすいようにcssフォルダ直下に配置してあります。
命名規則
まず完成形がこちら
.parent {}
.parent-child {}
.parent-child-grandChild {}
.parent-child-grandChild._modifier {}
<div class="parent">
<div class="parent-child">
<div class="parent-child-grandChild">
hogehoge
</div>
<div class="parent-child-grandChild _modifier">
fugafuga
</div>
</div>
</div>
- HTML構造に合わせて親・子・孫を
-
で区切る - 複数単語を使いたい場合はキャメルケースで書く
- モディファイアは接頭辞に
_
を付ける - クラス名のネストの数は3つまで
HTML構造に合わせて-
区切りにして、複数単語をキャメルケースにすることでクラス名からHTML構造を予測しやすくなります。
モディファイアの接頭辞に_
を付けることで直感的にわかりやすくなります。
utilitiesの命名規則
utilitiesは書きやすさを優先して プロパティの頭文字-値の頭文字
としています。
.ta-c { text-align: center; }
.fw-b { font-weight: bold; }
.jc-sb { justify-content: space-between; }
.mb-10 { margin-bottom: 10px; }
プロパティが被りそうな場合は補完して命名してください。
例: white-space: nowrap → ws-nowrap
例: (text-)color: var(--color-attention) → tc-attention
その他命名規則
- page配下のcssにはどのページで使われているクラスか判別するために接頭辞にページ名を付ける
top-module
,error-contents
- 命名規則に沿った書き方よりも 書きやすさ、可読性、統一性 が高ければ例外も認める
まとめ
- 先人の知恵は素晴らしい
- ガチガチにルール決めても人によって解釈が変わるんだったら、少し緩めのわかりやすいルールをメンバー全員で育てていった方がいいと思う
- 答えられる自信はないけど、こういう時どうするの?みたいな質問どしどし欲しい