CSSフレームワークを選ぶ際の観点5つ+おまけ #CSS

この記事の概要

Web サイトのスタイリングをするにあたり、いつの世も CSS フレームワークは使われています。
技術選定の基準が持てず苦労している人を見かけがちなので、私が見ているポイントを記事にしてみました。

この記事もあくまで「決定版」と言えるほどの内容ではありません。
しかしそれでも誰かの役に立てるかもしれないと思ったため、投稿してみます。

説明の都合上、具体的なフレームワーク名を出している場面もありますが、あくまで「私だったらこのアプローチを採択する/しない」の話です。
「これを使うべき/使ってはいけない」の主張ではありませんのでご了承ください。

見ているポイント

要素自体の見た目とレイアウトが分離できているか？

便宜上、自分自身の見た目に関するスタイル（background-colorやfont-sizeなど）をPresentational style、
ページ内での配置や関係性のスタイル（display: flex;やmarginなど）をLayout styleと呼ぶとして、以下のどれかが好ましいです。

Presentational style用のクラスとLayout style用のクラスが分かれており、任意の要素に複数のクラスを付与できる
Presentational style用のコンポーネントとLayout style用のコンポーネントが分かれている
Presentational style用のコンポーネントがあり、後からLayout styleを注入できる

これらの観点はかなり大事にしています。

例えば Bootstrap のAlertsはPresentational styleとLayout styleががっちり結びついていて、少し使いづらそうです。
以下が実際のコードなのですが、コンポーネントにmargin-bottomが指定されているのに注目してください。

.alert {
  position: relative;
  padding: 1rem 1rem;
  margin-bottom: 1rem; /* ←これ */
  border: 1px solid transparent;
  border-radius: 0.25rem;
}

たまたま余白が1remだったら良いのですが、そうでない場合も多いでしょう。
CSS では打ち消し回数が多くなればなるほど事故が起きるので、最初からこうやって指定されていると身構えてしまいます。

例外的なスタイルを無理なく適用できるか？

いきなり例外の話をしてしまいますが、フレームワークにつらみを感じるのは例外的なスタイルを組んでいる場面ではないでしょうか？

フレームワーク側の詳細度が高過ぎて!importantをつけないとスタイルを適用できない
JavaScript で値が動的に挿入されていて、どこから制御されているのか見えづらい

上記のようなパターンだと、オーバーライドすべきプロパティは分かっているのに諦めざるを得ない……なんてこともあるでしょう。
誰だって好きで負債を作りたい訳はありません。

「例外を作らず、フレームワークの way に乗って開発すべき」は間違いないですし、日々の開発ではそう努力すべきです。
しかし選定時は「もし例外的なスタイルが生まれてしまったら」を考慮に入れておいた方がベターだと考えています。

HTML 要素そのものにスタイルを当てすぎていないか？

reset や normalize の範疇を超えてのスタイルが当たっているかを見ます。

例えば h タグは文書構造と見た目が完全には紐付かない場合も少なくないはず。
毎度打ち消すのは面倒なので、あくまで「クラスに対応するスタイル」を提供してくれるフレームワークの方が好みです。

ただし、そもそも Classless CSS として提供されているものは別です。
通常の CSS フレームワークとは必要なタイミングや役割が違いますから、ここではあくまで Class 有りのフレームワークでの話に限定した観点です。

Classless CSS とは例えば以下のようなもので、CSS ファイルを読み込みさえすれば素の HTML を書くだけでそれなりに見た目が整います。

マークアップが過度にフレームワークに囚われないか？

スタイルとマークアップは密接な関係にありますから、ある程度はフレームワークの作法に則るしかありません。
しかし例えば「既定されたコードから、ネストを 1 段階も浅くも深くもできない」くらいガチガチになっていると結構しんどいです。

レスポンシブに対応するためなど、複雑めなマークアップ強いてくるフレームワークも見かけます。
スクラッチしたらもっと簡単じゃん！と思いながらフレームワークを使うのはかなり不毛なのでおすすめしません。

なおこの記事の主旨から外れますが、明らかなつらみが見えているときは「フレームワークを使わない」判断も候補に挙げられると楽になると思います。

素の CSS の書き方に近いか？

元も子もない話ですが、何の技術を使おうが最終的には CSS にコンパイルされます。
そのため、元々の CSS から離れれば離れるほど不都合が起きやすいはず。
（うっかりプロパティの名前を間違って覚えるとか、既存のコードを参考にしづらいとか、大きな問題ではないかもしれませんが……）

些細な話ながらも「最終候補に残った 2 つのうち、どちらが良いか迷うなあ」くらいの時期には意識します。

例えば Tailwind CSS では、ユーティリティクラスである都合上微妙に名前が違うものも多いです。

justify-content: space-between;がjustify-betweenというクラスで表現されているなど、些細な話ですが……。
通常の CSS の方がすぐに浮かぶ身としては、Tailwind 用の方言に変換するのに若干のラグを感じます。

優劣をつけたい訳ではありませんが、同じjustify-content: space-between;を表す際 Bulma はis-justify-content-space-betweenです。
個人的にはオリジナルに略されるよりは正式で長い方が好みです。

おまけ：z-index にとんでもない値を使っていないか？

非常に地味＆限定的な話ですが、一応記載します。
フレームワークというよりも、モーダルライブラリなどを選ぶ際の話に近い気がしますが……笑

私が出会ったことのあるものだとz-index: 2147483003;というとんでも無い数が使われておりげんなりしました。
なおz-indexの最大値は2147483647で、限界すれすれまで数値を上げていることも含めての感情です。

まとめ

要素自体の見た目とレイアウトが分離できているか？
例外的なスタイルを無理なく適用できるか？
HTML 要素そのものにスタイルを当てすぎていないか？
マークアップが過度にフレームワークに囚われないか？
素の CSS の書き方に近いか？
おまけ：z-index にとんでもない値を使っていないか？

最後まで読んでくださってありがとうございます！
Twitterでも情報を発信しているので、良かったらフォローお願いします！