12/3(土)にCSSを破綻させないということをbuilderscon tokyo 2016で話しました(動画見ましたが「えっと」や「なんか」とか言い過ぎなのと、髪の毛触りすぎですね)。
そこで使った発表資料の内容を編集した上で、CSS Advent Calendar 2016 14日目の記事として公開します。
CSSは破綻しやすい
OOCSSの提唱者Nicole Sulliban氏も"CSS is too fragile"と2008年のイベントで言いました。 なぜ破綻しやすいのか。それはCSSの特性が絡んでいます。
CSSの特性
CSSの特性としておもに3つあります。
はじめに、記述を間違えてもエラーにならないことです。ブラウザで表示確認をおこなって初めて見た目がおかしいことに気づきます。
次に、スタイルが適用される条件としてルールセットを書く順序は関係ありますが、常に関係があるわけではない点です。
ちなみにルールセットはCSSのセレクタ・プロパティ・値の定義をまとめたものです。 分かりやすい図としてCSS ルールセット構造図 · terkel.jp内の画像があるので引用します。
最後に、ルールセット間で同じプロパティが定義されている場合、順序・詳細度・重要度にもとづいて適用されるスタイルが決定されます。CSSをややこしくしているのはここですが、意識して書かないと容易に破綻します。
ここからは実際にCSSが破綻した例を見ていきます。
CSSの破綻
CSSの破綻はいくつか種類があります。これらの要素のうち2つ以上が複合して起きていると手がつけられないCSSになります。
スタイルの上書きが複数ある
スタイルの上書きはBootstrapなどCSSフレームワークを使うときに独自の見た目を実現しようとすると起こりがちな問題です。 スタイルの上書きが多くなるとどんな見た目になるのか予測できなくなり破綻します。
.button { border: 1px solid #ccc; } /* ...長いコードの後や別ファイルなど... */ .button { border: 1px solid #666; } /* ...長いコードの後や別ファイルなど... */ .article .button { border: 1px solid #00c; }
前に書いたセレクタの詳細度が高い
前に書いたセレクタの詳細度が高くてスタイルが上書きできないことも破綻の一因になります。
先ほどのスタイルの上書きを多くしていると起こりがちな問題です。
これがもたらす結果としては !important
の濫用です。
/* 詳細度はa=0, b=4, c=0なので0.4.0となる */ .container .form .form-group .form-submit-button {} /* 詳細度はa=0, b=1, c=0なので0.1.0となる 上書きできない。つらい */ .form__submit-button {}
命名規則がバラバラ
よくあることとして単語の区切りがケバブケース・キャメルケース・スネークケースのようにバラけていると、どの規則に合わせればいいのか分からずいつまでも命名規則が統一されません。
.account-login-button {} .commentSubmitButton {} .form_submit_button {}
CSSの破綻 まとめ
ここまでCSSが破綻する理由について書きました。まとめると次のとおりです。
- 詳細度が管理されていない
- ルールセットの分割粒度が明確ではない
- 命名規則が決まっていない
CSSを破綻させない
ここからはCSSを破綻させないためにはどうすればいいのかを書いていきます。
詳細度を管理する
CSSなどのファイルを分割するときはファイル内で下へ行くにつれて詳細度が高くなるようにします。またセレクタ定義やIDセレクタを書きすぎないようにするのも重要です。
例を挙げるとフォーム共通のスタイルを適用するときにセレクタを定義しすぎないことです。 これにより少ないセレクタ定義で適用したスタイルを上書きできて秩序が保つことができます。
/* 詳細度はa=0, b=2, c=0なので0.2.0となる */ .form .form-button { margin: 0; } /* ... */ /* 詳細度はa=0, b=2, c=0なので0.2.0となる 記述の順序が後なので値が上書きされる */ .comment-form .form-button { /* 上書きできる */ margin: 10px auto; }
ルールセットの分割粒度を明確にする
スタイルの上書きを減らすためにルールセットの分割粒度を明確にすることも重要です。 これはさまざまな方法が提案されていて、たとえばFLOCSSやSMACSS、ECSSなどがあります。
これは作るものによって適しているものが違うため一概にどれがいいか言えません。 スタイルを適用したいときにルールセットをどこに置けばいいのかチーム内で迷わないようにするのが重要です。
命名規則を決める
命名規則もMindBEMdingやECSS、SMACSSなどさまざまなものがあります。これもチーム内で使う命名規則を一致させることが重要です。
CSSを破綻させない まとめ
ここまでCSSの破綻を起こさないためにどうしたらいいか書きました。まとめると次のとおりです。
- 詳細度を管理する
- チーム内でルールセットの分割粒度を明確にする
- チーム内で命名規則を決める
しかしこれらを実践する前により大事なことが1つあります。 それはデザイナーとの認識合わせです。
これはデザインの意図を正確に理解した上で書かれたCSSは破綻しないという言葉があります。
デザイナーが作ったSketchやPhotoshopのファイルを見て質問や提案をおこない、デザイナーとUIを実装する人で意図の認識を合わせることが重要です。 もっと言うならSketchやPhotoshopなどで作る以前のプロトタイピングの段階から関わるとお互い意図の認識がしやすくなると思います。 プロトタイピングツールはPrott(ステマ)やInVisionが代表的です。
これを踏まえてまとめると、チームで議論して良いCSS設計を考えようになります。
CSSがすでに破綻している場合は?
buildersconのQ&Aで「途中から入ったプロジェクトのCSSが破綻していた場合どう改善したらいいのか?」というのがあったのですが、今のところチームで話し合って設計指針を決めて1から書き直すしかないと考えています。