FLOCSS（フロックス）は、人気の高いCSS設計手法の1つです。
CSSは複数人で作業したり、大規模なWebサイトになるとコード量が増えてしまい、途中で整合性が取れなくなったり、破綻してしまう場合があります。それを防ぐために必要なのがCSS設計手法で、しっかりとルールを定めてコードを書くことにより、管理しやすく、破綻しづらいCSSを記述することができます。
今回は、FLOCSSの基本や特徴をご紹介したいと思います。
INDEX
FLOCSS（フロックス）とは
FLOCSSは、「Foundation Layout Object CSS」の略称で、人気の高いCSS設計手法の1つです。
谷拓樹さんという日本人の方が提唱した手法で、日本語でのドキュメントも多く、Web上で多くの情報が公開されていたり、提唱者自ら電子書籍を出版されています。
OOCSSやSMACSS、BEM、SuitCSSなど他のCSS設計手法の影響を受けており、それらの設計手法の優れた点が取り入れられているのが特徴の1つとして挙げられます。
公式ドキュメントについては、Github上で公開されています。
FLOCSSの特徴
FLOCSSの特徴として、下記のようなものが挙げられます。
- ルールが細かく設定されているため複数人で作業しても破綻しづらい
- コンポーネントを再利用しやすい
- レイヤーで分割されているため管理しやすい
- クラス名から要素の役割がイメージしやすい
特に大規模なWebサイトになると、ページの数が増えるにつれてCSSのコード量も増えてしまいます。
そうすると、ページによってCSSの記述ルールが変わってしまったり、他のページにCSSが影響してしまったりなど、それだけ破綻しやすくなってしまいます。
そのような場合にCSSの設計手法は重要な役割を果たし、管理しやすく整ったコードを記述することができます。
FLOCSSは、どのようにCSSを区分し、そして記述するかについての細かなルールが設定されているため、それを元にコードを記述することで、複数人で作業した場合でも統一されたコードを記述することができます。
FLOCSSの3つのレイヤー
FLOCSSには3つのレイヤーの概念があり、CSSの役割によってそれぞれ区分されています。
FLOCSSの名前にもなっている「F・L・O」がそれぞれレイヤーの頭文字になっています。
- Foundation
- Layout
- Object
1. Foundation
そのWebサイト全体で利用するベースとなるCSSはFoundationレイヤーで定義します。
具体的には下記のようなものが当てはまります。
- リセットCSSやノーマライズCSS
- 全体の背景や基本的なタイポグラフィなどプロジェクト全体の基本となるスタイル
ざっくりと、全ページ、全要素に共通するようなCSSはFoundationレイヤーに記述するといいでしょう。
2. Layout
ヘッダーやフッター、メインとなるコンテンツエリア、サイドバーなどサイト全体で共通化されているようなレイアウトに関わる要素はLayoutレイヤーで定義します。
l-headerのように、プレフィックスとしてl-を付与しておく場合が多いです。
例えば、headerのHTMLは下記のようになります。
<header class="l-header">
<img src="xxx" class="l-header__logo" />
<nav class="l-header__nav">
...
</nav>
</header>3. Object
Objectレイヤーは、ほとんどの要素が位置づけられるレイヤーであり、その中でさらに3つに分けられています。
- Component
- Project
- Utility
Component
Componentは、再利用ができる最小限のパーツです。ボタンや見出しなどページの各所で使い回すような要素をComponentとして定義するようにします。
なるべく余計なスタイルは付与しないようにして、再利用性を考慮するようにします。マージンやサイズなどをComponentで定義せず、親要素から指定することで再利用性を意識したコードを記述することができます。
例えば、ボタンをComponentとして定義する場合、HTMLは下記のように記述します。
<div class="c-button">
<p class="c-button__txt">xxx</p>
<i class="c-button__icon"></i>
</div>Componentは最小限のパーツなので、その中に別のComponentを入れることはできません。
Project
Projectは、Componentやその他の要素によって構成される要素です。
Componentが最小限のパーツであるのに対して、Projectはもう少し大きな要素を指定します。
例えば、カードのスタイルをProjectとして定義する場合、HTMLは下記のように記述します。
<div class="p-card">
<img src="xxx" alt="" class="p-card__img">
<h3 class="p-card__title">xxx</h3>
</div>p-cardというProjectがあり、その中のComponentを除く子要素はp-card__xxxのようにクラス名を付与します。
Sassを使う場合は、ページごとにProjectのファイルを分割する形が多いです。
Utility
Utilityは、特定の要素だけ特有のスタイルを付与したい時に利用します。
具体的には、
- 特定の要素だけサイズを変えたい場合
- 特定の要素だけ色を変えたい場合
- 特定の要素だけマージンを変えたい場合
のような場合にUtilityを使用します。Utilityを適切に使うことで、無駄にComponentやProjectが増えすぎるのを防ぐことができますが、Utilityばかり使用してしまってもかえって分かりづらくなってしまうので、注意が必要です。
コンポーネントにmarginを定義してしまうと再利用性が低下してしまうため、下記のようにUtilityレイヤーでmarginを整えるクラスを定義しておくことができます。
.u-mbs {
margin-bottom: 10px;
}ComponentとProjectの違い
FLOCSSを複数人で運用していると、ComponentとProjectの違いがあいまいになってしまい、人によって粒度が異なるといったケースが出てきてしまうということがよく起こります。
特に、Projectの子要素にするか、Componentにするかの判断に悩むことが多くなると思います。
細かなルールは定められていませんが、ざっくりと他のプロジェクトやページで使用するものはComponent、そうでなければProjectと定義するという判断基準が定められているケースをよく見かけます。
ただし、基本的にはComponentもProjectも同じような使い方をすることができるので、厳密にルールを守るのではなく、チーム内で共通認識が持てていれば独自のルールを採用しても問題ありません。
FLOCSSの命名規則
FLOCSSの命名規則には、MindBEMdingが採用されています。
MindBEMdingは、「block__element–modifier」のようにクラス名を付与する命名規則であり、FLOCSSでもそのようにクラス名が定義されます。
FLOCSSの場合は、プレフィックスを付けることが推奨されているので、「p-block」や「p-block__element」のようなクラス名がそれぞれの要素に付与される形となります。
実際の現場では、「__」の代わりに単に「-」と付けているような場合もあり、厳密に上記のようなルールに則っていないケースもよく見かけられます。
プレフィックス
FLOCSSでは、基本的にクラス名にプレフィックス（接頭辞）を付与することが推奨されています。
具体的には、
- Layout：l-*
- Component：c-*
- Project：p-*
- Utility：u-*
のように、レイヤーに応じてそれぞれプレフィックスとなる文字が決まっており、クラス名の先頭に付けられます。
例えば、ボタンComponentであれば「c-button」、カードProjectであれば「p-card」のようにプレフィックスを付けます。
FLOCSSをうまく運用するコツ
JavaScript関連のクラスは「js-*」のようにプレフィックスを付ける
Webサイト内の特定の要素をJavaScriptで操作したい場合などは、「js-*」のようにプレフィックス付きのクラスを付与しておく運用がよく使われています。
こうしておくことにより、CSSとJavaScriptを切り離して考えることができるので、管理しやすく、読みやすいコードに仕上げることができます。
また、アクティブかどうかなど、状態を表す場合は「is-active」のように「is-*」の形でクラス名を付与します。
正しい解釈よりもチーム内のルール作りが大切
複数人でFLOCSSを使っていると、先に説明したようにComponentとProjectの違いや、Layoutの扱いなど細かな所で解釈に揺れが生じることがあります。
実際、企業やチームによってルールが異なるケースもあるため、チーム内でルールを明確にすることが重要です。
正直、正しいルールよりもチーム内での管理のしやすさ、コードの可読性が高い方法を選択することが正しいと思うので、チーム内で共通の認識を持てるようにルールを作ると複数人で作業しやすくなります。
ただし、ガチガチにルールを決めてしまうと、逆にコードが書きづらくなるケースもあるので、最適な落とし所を探してみましょう。
