FLOCSSというCSS設計手法を導入し、web制作をしてみたのですが、
調べてみるとオレ流FLOCSSがあるみたいなので、まとめてみました。
FLOCSSに関する基礎知識
FLOCSSとは？
FLOCSSとは、@hilokiさんが提唱したCSSの構成案・設計手法であり、SMACSSのようにモジュールを切り分けたり、MindBEMdingの命名を取り入れたりなど、他の有名なCSS設計を上手く取り入れて設計されてるという特徴があります。
公式ドキュメント : hiloki/flocss
FLOCSSのファイル構成
FLOCSSは、Foundation、Layout、Objectという３つのレイヤー層で構成されており、Objectレイヤー内に、Component、Project、Utilityという子レイヤーが存在しています。
🗂 Foundation (スタイルの下地になるもの)
└ (例) reset.scss
└ (例) setting.scss
└ (例) base.scss
└ (例) mixin.scss
🗂 Layout (headerやfooterなどの大枠のレイアウト)
└ (例) header.scss
└ (例) aside.scss
🗂 Object
└ 🗂 Component (再利用できるコンポーネント)
└ (例) button.scss
└ (例) icon.scss
└ (例) list.scss
└ 🗂 Project (プロジェクト自体のコンポーネント)
└ (例) articles.scss
└ (例) ranking.scss
└ 🗂 Utility (ユーティリティ)
└ (例) display.scss
└ (例) margin.scss
└ (例) text.scss
オレ流その1 - project？component？
FLOCSSで一番曖昧なのが、projectとcomponentの区別だと思います。
そのため、たくさんのオレ流を発見しました！
使用回数で区別する例
プロダクトの中で4回以上同じ Object が登場したらそれは Component
引用元 : FLOCSSを使ってCSSファイルを20,000行から9,000行にした話
運用してく際に、回数を数えなきゃいけなかったり、接頭語でprojectとcomponentを分けていたりしたら少々リファクタリングが大変そうだけど、全員が共通認識をもってproject、componentの区別ができそうですね！
有名サービスを参考にして区別する例
FLOCSSのcomponentとprojectの判別を迷わないために、PowerPointの図形を使って以下のように決めました。
component：パワポの図形１つの単位
project：グループ化して動かす単位
とりあえずこれでチーム全員が「これは最小単位のモジュールだ」と判別できる基準をもつことができました。
引用元 : FLOCSSを使ったCSS設計での悩みどころと解決案
記事が非常にわかりやすくて感動しました...！(ただの感想ですね)
有名なサービスを例に挙げるのは、共通認識の取りやすいため運用していく上でgoodだと思いました。
Atomic Designを参考に区別する例
Atomic Designでいう、AtomsをComponent、Molecules等Atoms以外をProjectとしました。
再利用性の高い粒度の小さいコンポーネントがComponentのイメージです。
引用元 : 脱・CSS無法地帯。FLOCSSで指針のある設計を。
公式に一番近い考え方かなと思います！
しかし、Atomic Designでも「このボタン、アイコンもテキストも入っちゃってるけどAtomとMoleculeどっち？！機能的にはAtomなのかな...」ってなりがちなので、Atomic Designを完璧にしていないと迷っちゃいそうですね。
よく使うコンポーネントの土台(枠線があるということや、複数部品の相対的な関係性など)をcomponentに書いていきます。特に理由のない時(大きさも含めサイズ・色にバリエーションがない時)は色・大きさと言った具体的な設定は次のProject層に分けて書くことにしています。複数の要素からなる時に相対的は大きさや位置をemなど相対的な単位で設定します。
引用元 : 三年間運用しているサービスにFLOCSSを導入してCSSの健全化を目指す
Atomic Designに近い考え方ですね！
機能を持つ最小単位のatomをComponentって考えると一見わかりやすそうだなって思いました。
ページ専用のコンポーネントをProjectに区別する例
Projectレイヤーは他のページでは使い回さない特定のページ専用のスタイルを書く
引用元 : FLOCSSベースのオレオレCSS設計の紹介
これは次章に書きましたpageディレクトリとProjectを同じ扱いにした感じですね。
オレ流その2 - pageディレクトリ
サイトによっては、pageごとでデザインがガラリと変わる...ってこともありますよね。
そのような際に使えるFLOCSSオレ流です！
いわゆるshame.cssです。(ちょっと言葉が過激だなと感じていますが)
コンポーネントの幅がページ固有の要件の場合、CSSの分類が非常に難しく、page専用のスタイルを定義するファイルを用意しました。
引用元 : 脱・CSS無法地帯。FLOCSSで指針のある設計を。
オレ流その3 - 単語とその接続部
MindBEMdingのルールとしては、.Block__Element--ModifierというようにElementをハイフン2つ、Modifireをハイフン2つで繋げます。
しかし、公式ドキュメントにも命名規則の微調整が提案されており、オレ流ルールが生まれたりします。
単語の繋げ方
単語をハイフンで繋げる例
.block-name {}
.block-name__element {}
.block-name--modifier {}
単語をキャメルケースで繋げる例
.blockName {}
.blockName__element {}
.blockName--modifier {}
Block、Element、Modifierの区切り方
ハイフン、アンダーバーを一つ減らし、キャメルケースで単語を繋げる例
.blockName {}
.blockName_element {}
.blockName-modifier {}
オレ流その4 - 接頭語の有無
HTML上のクラスの見分けやすさや、名前空間の衝突の回避のためにプレフィックスをつけたりします。個人的には、utilityなど複数クラスを付与する可能性か高いため、プレフィックスはつけたほうが良いと思います。
プレフィックスの付け方
layout - l-*
component - c-*
project - p-*
utility - u-*
引用元 : 脱・CSS無法地帯。FLOCSSで指針のある設計を。
オレ流その4 - Element、Modifierの数
命名が長くなりすぎたり、Elementが入り組みすぎたり、Modifierが上書きされすぎてしまったりしないように、Element、Modifierの数に制限を決めるとより良い命名ができるでしょう。
それぞれElement、Modifierを２つ作成しないことにしました。
BEM導入にあたって、ひとつ躓くポイントの一つとしてElementとModifierをどこまで厳密に再現するかではないでしょうか。
例えば、.modal__header--blue__btn--red__text--small {}
というように、BEMではあまりにもクラス名が長くなるケースがあります。
そこで、Blockに対する子要素を明示できれば、運用上大きく問題は生じないと判断し、ElementとModifierを２つ作らないようにしました。
引用元 : 脱・CSS無法地帯。FLOCSSで指針のある設計を。
オレ流その5 - layoutの扱い
「正直、layout層っていらなくない?」ってことも多いようです。
設計者である谷さん自身も「ここだけの話な、FLOCSSのLは別にいらんで」っておっしゃってるくらいなので、layoutの有無はサービスごとにお任せですが、
谷さんご本人は『みんなが知ってるような知らないようなFLOCSSの話』にてこのようにおっしゃってます。
- レイアウトとしてのHeaderと機能を持ったモジュールとしてのHeaderをわける
- Layoutが何もスタイルを持たないこともある
- けど個人的にはclassをつけておく コンテンツの性質を表しているから
以上、みんなのオレ流FLOCSSをまとめてみました。
しかし大事なことは、単にFLOCSSを導入してこのオレ流FLOCSSを参考に改良してみることではなくて、コードを書く人みんなが共通認識を持ってルールにしたがって破綻しないようにスタイルを当てられることだと思います。