ここ数年くらい、自分の中のCSS設計はFLOCSSベースで割と安定しているかなと思ってるので、制作会社のブログっぽくCSS設計に関して何やかんや書いてみたいと思います。
今回の内容はあくまでも自分のCSS設計ってこんな感じですよって話なので、「平澤ってこういう風に設計してんのね、ふーん。」程度でお願いします。
コレを参考にして破綻したって責任は持てません!
FLOCSSを選んだ理由
色んなCSS設計を調べたりして検討していた頃、最終的に落ち着いたのが谷さんが提唱してるFLOCSS(フロックス)でした。
FLOCSSを提唱してる谷さんは、Web制作者のためのCSS設計の教科書の著者でも有るので、書籍を購入してFLOCSSを参考にした方も多いのではないでしょうか?
と、ちゃっかりアフィID貼ってAmazonにリンクしておきましたので、CSS設計ってなんです?って方はちょっと古い本ですが、ご購入頂けるとよろしいかと思います。
最終的にFLOCSSに落ち着いた理由としては、今まで自分がやってきた設計やら考え方から大幅に変更しなくても採用しやすいってのと、公式のドキュメントが日本語で書かれてるのは、より多くの人が誤解せずに理解できるかなって思ったりしたので選んだような気がします。
他に、命名規則に有名なMindBEMdingを採用してたのも大きいかも。
なんだかやたらとBEM!BEM!言い始めた頃(何年前だ!?)、アンダースコア2つが気持ち悪くてダメだなーと思ってたのが懐かしい。
FLOCSSベースのオレオレCSS設計
ここからが本題でしょうか。FLOCSSをベースにしたオレオレCSS設計のご紹介です。
CSSっても最近はSassでしか書かないのでSass使ってる前提です。
Sassってなんだ?って方は「Web制作者のためのSassの教科書 改訂2版」がオススメです!
Modifierは、ハイフン始まりに変更
これは、BEM的にも一貫したルールが有れば変更OKなので、FLOCSSを変えてるってのとはちょっと違うんですが、ModifierはBlock名から繋げずにハイフン始まりから書くようにしてます。
初めてこの書き方を見た時に、コレは見やすいな!って思ったのでソッコー真似しました。
単純にブロック名を毎回書くのも面倒ですし、個人的にコレは結構オススメしたい。
class名はキャメルケース
class名には、.blockName__elementName.-modifierName
のような感じで、キャメルケースを使ってます。
スネークケースだとアンダースコア2つのMindBEMdingの命名規則と勘違いしやすいし、ハイフン使うチェインケースだとプレフィックスとして使う場合の区別が付き難いので、キャメルケースにしてます。
Objectのプレフィックスは付けない
FLOCSSでは、Componentなら「.c-button
」、Utilityなら「.u-mb10
」みたいな感じでプレフィックスをつけることを推奨していますが、ボクの場合は基本的にObjectのプレフィックスは付与しません。
コレに関しては、後述するObject内のProjectレイヤーの考え方が違う部分も有りますが、別の用途でプレフィックスを使いたいのでごちゃごちゃしたくないってのと単純に面倒なのも有ります。
Projectレイヤーはページ固有で使う
FLOCSSのドキュメントを読んでて一番分かり難いと言うか、制作者に判断が委ねられやすいと思ったのがProjectレイヤーです。
公式にはこんな感じで書いてあります。
プロジェクト固有のパターンであり、いくつかのComponentと、それに該当しない要素によって構成されるものを定義します。
例えば、記事一覧や、ユーザープロフィール、画像ギャラリーなどコンテンツを構成する要素などが該当します。
分かるような分かんないような。
コレに関してはやはり判断に悩む人が多いのか、FLOCSS関連を取り上げてるブログ記事を読んでても、ComponentにするかProjectにするか悩むって書いてる人も居ました。
ボクもこの判断って結構微妙だなーと思ったので、Projectレイヤーは他のページでは使い回さない特定のページ専用のスタイルを書く際に使うようにしています。
また、この際ファイル名をプレフィックスとして使います。
例えば、採用情報ページで「jobs.html」ってページが有った場合、
みたいな感じで「jobs」をプレフィックスとして使うことで、そのページ専用のスタイルですよって感じにしてます。
このルールを設けることで、ComponentなのかProjectなのか悩まずに済むのが良いなと思ってます。
注意点と言うか気をつけてる点としては、リニューアル時とか新規構築時点でそのページ専用のデザインでも、デザイン的に汎用性が高そうな場合やページが増えた際に使われそうなデザインの場合、Projectにしてしまうと使い回せないのでComponentにしてます。
似てるけどちょっと違うデザインパターンならModifierとして派生パターンにするし、流用されそうならComponent、ほぼ間違いなく唯一ならProjectって感じです。
Blockは、アンパサンドを使って書く
FLOCSSはあんまり関係無いですが、先程のサンプルのSassソースでも使ってるように、&__element
みたいにアンパサンド(&)を使って書く派です。
デメリットの方が多いって意見も有りますが、アンパサンドを使った方が効率よく書けるし、後からBlock名を変更したい場合も1箇所変えるだけで済むし、Block名が長いとごちゃっとするので、使った方がメリットが有るって思ってます。
検索できないとかは、Sassファイルの分割をBlock単位で行えば、一つのSassファイル内ではそこまで行数が増えないので、わざわざ検索するほどの行数にもならないですし、一つのBlockに対してElementが何百になるって考えにくいので、アンパサンドを使って後悔するってケースは無かったと思います。
ヘッダーとフッターは色々例外扱い
Layoutレイヤーに属するヘッダーやフッターに関しては、MindBEMdingも採用せず、従来通りにカスケーディングして書くことがわりと多いです。
詳細度がある程度上がってしまうけど、ヘッダーやフッターに関しては変更が発生するとしてもメインコンテンツ内で流用するとかって事を想定する必要も無いので、ヘッダー内の全ての要素のスタイルは同じSassファイル内に書いちゃってます。
この辺りはけっこう悩んでる部分でも有るので、書いた時期によっては次のように書いてる時も有ります。
そもそも、Layoutレイヤーに内包する要素全てのスタイルをまとめちゃうのはFLOCSS的に違うかもしれないけど、ヘッダーやフッターって使い回すことがほぼ無いので、まとめて書いちゃった方が分かりやすいかなーと思ってます。
p要素やli要素にはあんまりclassを振らない
これはケースバイケースなので一概には言えない部分ですが、例えばli要素の場合、次のようにul要素にはclass付与するけどli要素にまでは振らない事が多いです。
BEMやMindBEMdingの良い所はマークアップに依存せず使い回せる点も大きいですが、ul要素の後にli要素以外来ること無いし面倒だし良いか。みたいな理由でclass振らないことが有ります。
p要素も次のようにclass振らずに増やせるようにすることが多いです。
p要素にclass振らないのは、そのp要素が増える可能性が有るか無いかってのが判断基準になってます。
また、CMS使ってたりブログで書いたりする場合、毎回class振るなんて面倒だしお客さんにそんな事お願いするのは酷だと思うので、ガチガチにやり過ぎないように自分なりにバランス見つつやるって感じです。
もちろん、段落が増える可能性が無かったりする場合は、普通にp要素にもclass付与して対応する事も有ります。
プラグインとかライブラリ関係はlibディレクトリに
slickとかcolorboxみたいなプラグインを使う場合、それらのCSS(Sass)ファイルは、FLOCSSのレイヤー構造だとどこに入れたら適切なのか分かんなかったので、Foundation、Layout、Objectなどと同列に「lib」を追加して入れてます。
おわりに
細かいオレオレルールはまだ有るけど疲れてきたのでこの辺りでおしまいです。
FLOCSSベースにしてからわりと安定してる感は有るけど、まだまだ迷いながら組んでることは多いです。
FLOCSSに関してもまだまだ理解が足りないと思ったりするので、ちょうど良いタイミングって事で技術書典5に参加してFLOCSSの解説書をゲットしてこようと思います。
印刷間に合わせのサークルカット。この内容でひきかえせないぞ!「柴犬でもわかるFLOCSS」 #技術書典5 pic.twitter.com/3Sxnpa9Dwy
— Hiroki Tani: 技術書典5/う60 (@hiloki) 2018年8月27日
柴犬以下の自分でも分かると良いんだけど!
という訳で、誰の役にも立たないようなオレオレCSS設計に関して紹介してみました。
CSS設計って悩ましいけど、ぶっちゃけワイヤーフレームとデザインの段階で良い感じに設計できるかどうかなんてほぼ決まっちゃうよね!
なんでデザインが異なるのか全く理解できない似て非なるデザインが大量に増えていくから破綻するとおもry…