STaD vol.4 : 今どきなCSS設計って？（OOCSS,BEM,SMACSS,FLOCSS,RSCSS）
月1回開催している、個人のクリエイター・エンジニアによる勉強会 STaD。
今回は普段私と東崎さんが席を置いている鎌万オフィスで、いつもお世話になっている10T株式会社の方たちがランチを振る舞ってくれるというありがたいお声がけをいただいたので、まずはメンバー全員でいただくことに。
マムこと正心さんお手製のお料理は、見た目も美しいが、口に入れると「めちゃうまし！」
素材をそのまま生かしつつ、ひとつひとつの味付けはしっかりされていてそれでいて個性的。
ごちそうさまでした！
ランチ後は、いつものごとく鎌倉駅近にあるシェアオフィス、旅する仕事場に移動。今回のお題は"CSS設計"。
メンバーは全員普段からフロントをやっていて、プロジェクトによって一緒に仕事をすることもあるので、CSSルールを揃えておきたいという意図もあります。
勉強会はこのような流れで進めていきました。
1. 事前にいくつかの参考サイトを見ておく
2. 今どきなCSS紹介
（OOCSS, BEM, SMACSS, FLOCSS, RSCSS）
3. 普段どんなCSSルール使ってる？
4. 今後どのルールでやるのがよいかディスカッション
今どきなCSSとは？ なぜ必要？
マルチデバイス対応が実装に必要になってから、コーディングという仕事の難易度が一気にあがりました。
具体的には、デバイスのサイズによってブレークポイントを設けて、デザイナーからもらったデザインを見越しながら、見た目の変化に対応した記述を都度する必要があるのと、中間デバイスの"つじつま合わせ"みたいな事細かな調整などが必要となりました。
こうなると単純に記述量も増えますし、闇雲にノリでコードを記述するとソースがカオス状態になってしまいます。そうならないためにも、それなりにルール化が必要となった。ということだと思います。
"コーダ—"と呼ばれていた職業が、"フロントエンジニア"というちょっといけてるネーミングに変化した所以も、HTML, CSS, Javascript開発をある種ノリでやっていた時代から、バックエンドエンジニアがやっているように、オブジェクト指向なルール化や、モジュール化をしておけば、サイトの運用やチームでの開発がスムーズに進めることができるという理由もあると思います。
それではこの日勉強会で紹介したCSSルールを OOCSS → BEM → SMACSS → FLOCSS → RSCSS という順番で簡単に紹介したいと思います。
OOCSS
BootStrapで使用されいている（開発された？）ルールです。CSSルールって必要なんだ—と考えさせられるきっかけとなったルールかもしれません。
例えばボタンであれば、形や色、サイズ、余白、その他用途で、それぞれ個別にClassを作っておき、HTML上ではその中から必要なクラスを組み合わせて、形作ります。
<button class="btn btn-lg btn-pink600_ftg">
btn-pink600_ftg
</button>マージンや余白だけのCSSを予めたくさん準備しておいて、その機能だけのクラスを足していく、というやりかたもこのルール概念のひとつかなと思います。
このようなCSSは"マルチクラス"とも言いますね。
メリット
□ クラスを使い回せる
↓
自分の決まったレイアウトパターンを持っていて、それを仕事で使うことができるというような人であれば、新しいクラスをあまり作ること無く、バク速で組める。
デメリット
□ スタイルによって微妙なマージンなどの違いを埋め合わせようとするとどんどんクラスが増えてカオスになる可能性大。
□ 他のレイアウトにも影響してしまうため、修正をかけづらい
↓
特設サイトなど、仕事によって色々なデザインパターンを実装することが多い人には難しい。
BEM（Block__Element—Modifier）
こちらはクラス名の命名ルールとでもいいましょうか。
筆者はこのルールに出会ってからすごく実装のストレスが無くなりました。
BEMはCSS名の付け方を Block、Element、Modifierの3つの要素で構成します。
.block__element--modifier
詳しい説明は以下のサイトでご参考ください。
▼参考
BEMという命名規則とSass 3.3の新しい記法
http://blog.ruedap.com/2013/10/29/block-element-modifier
BEMによるフロントエンドの設計（Code Grid）
https://app.codegrid.net/entry/bem-basic-1
メリット
□ クラス名が独自なのでまず被ることは無い
□ 余計なことを考えず、どんどんクラスを作ることができる
□ 名前を見て何を意味するか判別しやすい
デメリット
□ ブロックの入れ子が多いとクラス名がやたらと長くなり、ソースが見づらくなる
□ HTMLのコードが増えがち
BEMを取り入れた当初は、クラス名が長くなってしまうことに抵抗があったのですが、「クラス名を短くしてソースをすっきりさせたい」というプライドさえ捨ててしまえば（笑）、Block 以降の Element や Modifire の名前付けは被ってもOKなので、あまり余計なことを考えずどんどんスタイル付けができてよいです。
クラス名をひとつひとつ付けていくようなイメージなので、スタイルが増えてしまって記述した場所を探すのが難しくなるのでは？という懸念もあると思いますが、例えばAboutページのスタイルであれば
.about__xx--xx
みたいな感じでCSSファイル内にAboutに関するクラスがまとまり関連クラスが分散することもすくなくなり探しやすく、編集しやすくなると思います。
また、エディタにはだいたいショートカットキーがあって、HTMLに記述してあるクラス名から、編集したいCSSファイルのクラス名までジャンプできたりするので、むしろ名前が個別に分かれているぶん、検索がしやすくなった印象すらあります。
最後に紹介するFLOCSS含め、今のCSSの命名ルールの基本ともなっているので、まず覚えておいて損はないでしょう。
SMACSS
こちらはCSS設計において、モジュール化するためのパターンの提唱とでも言いましょうか、CSSの命名を、意味合いに合わせて分けて、上手に管理しましょう。というものです。
こちらもBEMと同じく命名ルールですが、BEMよりもう少し大枠の概念だと思います。
詳しくは以下のQiitaの記事が参考になります
▼SMACSS+BEMによるテーマ設計
https://qiita.com/J_Sugar__/items/9adee163028c9910fbc6
上の記事から引用ですが、SMACSS は以下の5つのカテゴリから構成されています。
■ ベース
body や a タグなどHTML要素そのもののデフォルトスタイル
■ レイアウト
ページの骨組み部分。header や footer などのエリアごとに定義する
■ モジュール
再利用可能なパーツ（OOCSS的な）
■ ステート（状態）
レイアウトやモジュールの特定の状態を示す（要素が選択されているなど）
■ テーマ
サイトの視覚的な部分。例えば英サイトの時にテーマを切り替えるなど
SMACSSとBEMの命名ルールを組み合わせれば、より管理されたCSSになると思います。
FLOCSS
こちらはSMACSSのさらに大枠の概念といいますか、CSSファイルを意味合い事にファイル分け（モジュール化）してうまく管理しましょうというものです。
詳しくはこちらをご参考ください。（Qiita）
https://qiita.com/sueshin/items/dcbaf3d8a0adb6b087db
上からの引用になりますが、以下のようなファイル構成になります。
├──foundation/
├──layout/
└──object/
├──component/
├──project/
└──utility/■ foundation
Reset.cssなど土台となるCSS群。
■ layout
header, sidebar, footerなどのレイアウト用CSS群
■ object/component
再利用できる小さなコンポーネントCSS群
■ object/project
プロジェクト固有のコンポーネントCSS群
■ object/utility
ユーティリティクラスを定義するCSS群
最終的にはこのFLOCSSのモジュール化の概念と、BEM、SMACSSの命名ルールを組み合わせることで、管理されたCSSを作ることができそうです。
他にも参考になるサイトを掲載しますのでご覧ください。
▼ CSSの設計 – FLOCSSをベースにしたファイルの構成と命名規則を考える
https://www.tam-tam.co.jp/tipsnote/html_css/post10205.html
▼ 破綻しにくい CSS 設計手法と命名規則https://murashun.jp/blog/20170729-01.html
▼ FLOCSSを使ってCSSファイルを20,000行から9,000行にした話
https://qiita.com/Atsss/items/4f9d98fb1d0546539c09
RSCSS
最後にRSCSSをご紹介します。
RSCSSはBEMのデメリットであるクラス名が冗長になるところを子セレクタ（>）を使用することで、解消しようという考え方です。
BEMではCSSのネスト（入れ子）はNGですが、RSCSSではOKということになります。
ただ、入れ子にする場合にBEM的命名ルールに則って入れ込めばBEM的命名ルールのメリットを使いつつ、HTMLもスッキリさせることができて一石二鳥だ！というところでしょうか。
筆者はまだちゃんと使ってないのですが、マルチクラス的な使い回しができないということと、HTMLからショートカットで編集したい目当てのクラスに一発でジャンプできないのではないかという不安もあったり（それはブロック名からジャンプすればよいのか）なんとなくBEMとの共存が難しいそうな雰囲気は感じます。
参考
▼ RSCSS というCSS設計について（Qiita）
https://qiita.com/kk6/items/760efba180ec526903db
まとめ
結局の所、現時点でどのような命名ルールで開発するのがベストなのでしょうか。
こちらは勉強会でも議論の対象になったところですが、100%これがいい！というものはなく、これまで紹介してきたような命名ルールをうまく組み合わせて、自分が使いやすいようにしていく、というところでなんとなく落ち着きました。
ただ、FLOCSS + SMACSS, BEM を軸に置きながら開発するのはよさそうです。そこに RSCSS も一部使用するイメージでしょうか。
ある程度ルール化ができれば開発が楽になりますし、チーム間でも共通認識が持てて連携がスムーズにいくと思います。
あとは案件によって、微妙にルールが変わったり、今後CSSルールも進化していくと思われるので、都度アップデートさせていくという感じかなと。
それから、単純に命名のセンスも問われると思うので、そちらもチーム間ですり合わせするとよりよいかもしれません。
名前付けって以外に時間掛かりますよね。
あー、もう日本語でつけちゃえ！とか（笑）
いやー、たかがCSS、されどCSSですね〜
