FLOCSSを使って破綻しにくいCSS設計を！

2019年11月22日2021年11月28日

CSS設計をしっかり行うことで破綻のしにくく再利用しやすい、保守性の高いCSSを書くことができるようになります。CSS設計の手法は有名なものがいくつかあるのですが、自分が（今のところ）好きなのはFLOCSSです。
→ FLOCSSの公式ドキュメント

この記事では、FLOCSSの基本的な考え方と自分の解釈の仕方について紹介していけたらと思います。

FLOCSSとは？

FLOCSSは、株式会社サイバーエージェントのエンジニアであるHiroki Taniさんが提唱したCSS設計手法で、日本人が作成していてドキュメントが日本語ということで、日本での利用頻度が高まっていると思われる（実際の数字は知らない…）CSS設計になります。

ドキュメントはGithubのREADME.mdがすべてです。
→ FLOCSSの公式ドキュメント

また、CSS設計の本といえばこの本！という「Web制作者のためのCSS設計の教科書」の著者でもあるので、FLOCSS含めて考え方を学ぶには最適な1冊なので、基本についてはこちらを読んでみてください。

Web制作者のためのCSS設計の教科書モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 Web制作者のための教科書シリーズ

著:谷拓樹

Amazon

楽天市場

ポチップ

この記事では個人的に大事だと思う部分を自分の解釈と共に紹介していくような感じとなります。

FLOCSSの書き方

FLOCSSは大きくは「Foundation」「Layout」「Object」の3つ。そして。「Object」の中の「Component」「Project」「Utility」から成り立っています。この5つの構成を正しく守り順番に読み込むことで破綻しにくいCSSとなるわけです。

それぞれに記載する内容をざっくり分けると以下のような感じです。

Foundation ・・・要素の初期化やmixinなどのベースを設定。リセットCSSなど。
Layout ・・・ヘッダーやフッターなど大枠のレイアウトに関する定義。装飾はなく枠だけを用意しているイメージ。
Component ・・・再利用ができる最小限のパーツ。どの案件でも使える単位でのパーツです。
Project ・・・サイト固有のまとまりを定義してパターン化するパーツ。案件に応じて追加していくパーツです。
Utility ・・・ちょっとした調整のために使われます。余白の調整や非表示など。

ものすごく唐突ですが、FLOCSSベースで以下のようなCSSテンプレートを以前作成しました。ダンロードすればFLOCSSのファイル構成などはおおよそ分かるのでぜひ見てみてください（名前は仮）
→ CSSParts｜HTMLコーディングを効率化するCSSテンプレート

FLOCSSの命名規則（ネーミングルール）

命名規則とは、簡単にいうとクラス名の付け方ですね。

BEMがベース

FLOCSSのネーミングルールは、BEMがベースとなっています。ここではBEMについて詳しく説明しませんが、「Block」「Element」「Modifier」の3つの役割を分かりやすく記載する方法です。

プレフィックス（接頭辞）をつける

BEMとは異なるFLOCSS特有のルールとしては、プレフィックス（接頭辞）をつけるという点になります。「Component」には.c-、「Project」には.p-、「Utility」には.u-をそれぞれ付与します。

汎用的に使えるボタンの「Component」クラスを作るとすると、例えば.c-buttonという名前で作成するといった具合ですね。

プロジェクト単位で使う記事用の汎用クラスを作るなら「Project」で.p-entry-itemといった感じになります「Component」と「Project」の切り分ける考え方としては、他の案件でも使えそうなら「Component」、この案件でしか使えそうにないなら「Project」といった考え方でいいかと思います（話がちょっと脱線しました…）

「Utility」は、「スマホだけ非表示にする」とか、「10pxの余白」みたいな調整用のクラスを定義する部分で、どういったものを定義するかはBootstrapなどのメジャーなCSS設計を参考にしてもらえたらと思うのですが、.u-hidden-spのような形で定義して、HTML側から非表示にしたい要素に対して適応していくようなイメージです。

状態をもたせる場合

アクティブになった時、など状態を表す場合は、is-というSMACSSでのCSS設計パターンも用いることが可能です。ボタンがクリックされた時と表したい場合は、.c-button.is-clickみたいな書き方も可能になります。

読み込む順番

「Foundation」「Layout」「Component」「Project」「Utility」の5つから成り立つFLOCSSですが、正しい順番で読み込むことで破綻しにくいCSSとなります。具体的には以下の順番です。

@import "foundation/**";
@import "layout/**";
@import "component/**";
@import "project/**";
@import "utility/**";

上記の書き方は「gulp-sass-glob」を使ってまとめてしまっていますが、foundation内などちゃんと順番を決めて読み込まないとダメなケースもあるので、大枠の順番と、書くフォルダ内の読み込み順番も意識した方がいいかもしれません。

FLOCSSに関する（勝手に）Q & A

自分がFLOCSSを触った時に感じた疑問を勝手に自問自答します。

「Layout」っている？

わたしが使っていて真っ先に感じたのが「Layout」の役割の薄さ…。「Layout」は、「○%で横並びにする」であったり、「横幅100%にする」みたいな、レイアウトに関する見栄えのCSSだけを持つ部分です。

「全部「Project」でよくね？」って思ったりしましたが、「Component」や「Project」を横幅とかに依存せずにキープするって考えると、大枠を囲う意味は必要になってくるのかなと思います。

具体的なコードとしては以下のような感じかと。これなら.p-headerの「Project」をレイアウト部分と分離して管理できるようになります。（つまりは、別のレイアウトに移動して組み込むことが容易になるということです。）

<header class="l-header">
	<div class="p-header">
		<div class="p-header__logo">ロゴ</div><!-- /p-header-logo -->
		<nav class="p-header__nav">
			<ul class="c-navigation">
				<li><a href=""></a>メニュー1</li>
				<li><a href=""></a>メニュー2</li>
				<li><a href=""></a>メニュー3</li>
			</ul><!-- /c-navigation -->
		</nav><!-- /p-header__nav -->
	</div><!-- /p-header -->
</header><!-- /l-header -->

「Component」か「Project」にするか迷う…

FLOCSSでたぶん一番質問が多いであろう、このパーツは「Component」か「Project」のどっちにしますか？っていうもの。個人的な解釈としては、他の案件でも使えるなら「Component」。この案件でしか使えないなら「Project」といったイメージです。

わたしは迷ったら「Project」って感じにしています。

`mixin`や`function`や定数はどこ？

FLOCSSでは、定義系は全部「Foundation」で管理します。「Foundation」では、リセットCSSや、要素に対する標準のCSSも定義したりするので、もしここで変数を使うなら、読み込む順番を意識しないとエラーとなります。
（もしかしたらFLOCSSでは変数や関数を使わない説もあり…）

setting.scss
function.scss
reset.scss
base.scss

みたいな感じで読み込む順番を指定してあげた方が無難です。

idは使ってOK？

公式のドキュメントを見ると「Layout」については、#headerが例に挙がっています。

抜粋すると以下のような感じです。

ただしIDセレクタは高い詳細度を持つため、それを懸念する場合には、l-* プレフィックスをつけた命名を採用するか、あるいは [id="header"] のような属性セレクタを用いることを推奨します。

この文章を簡単に言うと、「Layout」は以下のどちらかで記載しましょう、というものです。

.l-header
#header

他のプレフィックスの命名規則を考えると.l-の方がしっくりくるのですが、idを使うことに抵抗がなければどちらを利用してもOKということです。

「Component」を上書きしてもいい？

「Component」は単体で成り立つように作るべき（もし見栄えを変えたい場合は「Component」で「Modify」を追加する）ですが、FLOCSSでは例外として親の「Project」から上書きはOKとしています。

例外として、レイヤー間におけるカスケーディング、例えば、次のようなProjectレイヤーがComponentレイヤーのモジュールを変更することは許容します。
https://github.com/hiloki/flocss

<div class="p-profile c-media">
  <img src="user.jpg" class="c-media__image">
  <div class="c-media__body">...</div>
</div>

// Component
.c-media__image {
  float: left;
  margin-left: 10px;
}

.p-profile > .c-media__image {
  float: right;
  margin-left: 0; // Cancel '.c-media__image' value
  margin-right: 10px;
}

あまりスマートな書き方でないことは確かですが…

FLOCSSの拡張（勝手に…）

FLOCSSを触っていて自分なりに「こうしたい！」って部分があるので、自分1人でFLOCSSやる時は微妙に拡張しています。ついでというかおまけ的な感じで共有します。

チームで拡張する場合は、全体での共有は必須です。

設定部分は分ける

要素の初期化でも変数を使いたいわたしは、「Foundation」内にまとまっている作りがちょっと馴染めませんでした…。というのもフォルダ内のまとまりは、順不同で読み込んでも機能するのがキレイだなってイメージがあったためです。

2つのフォルダを追加しています。

「setting」には、変数の定義と値の設定
「function」では、mixinとfunctionの定義

をそれぞれ書いています。

そして、全体の読み込みは以下のような順番となります。

@import "setting/**";
@import "function/**";
@import "foundation/**";
@import "layout/**";
@import "component/**";
@import "project/**";
@import "utility/**";

JavaScriptと関わる部分は`.js-`のプレフィックスを付与

CSSのクラスの中でもJavScriptと結びつくクラスがあるかと思います。

JavScriptと連動しているクラスには.js-btnのような感じでJavaScriptと連動していることを明示してあげると、後の人が誤って消したりするリスクが減るはずです。

.js-には見栄えに関する記述は一切せずに、あくまでもJavaScript側で使うだけの用途となります。

サイト内リンクの受け取りは`#a-`プレフィックスのid

ページ内リンクでhref="#hoge"といった指定することがあります。この移動先はIDで指定する必要がありますが、ここも分かりやすくするために、id="a-hoge"と記載してあげれば、メージ内リンクの移動先用のIDであることがひと目で分かります。

先ほどのJavaScriptと同様に、見栄えで使われないIDってことで誰かが誤って消したりするリスクを減らすための記述です。

外部ライブラリのCSSを上書きする「External」

実際に案件をしていると、外部ライブラリで使われているCSSを上書きしたいケースが出てきます。この外部ライブラリを上書きする用の場所を用意してあげます。

名前は何でもいいと思いますが「External」と名前を付けていて、これはFLOCSSの一番最後に読み込ませる部分となります。

@import "setting/**";
@import "function/**";
@import "foundation/**";
@import "layout/**";
@import "component/**";
@import "project/**";
@import "utility/**";
@import "external/**";

例えば、Swiperのクラスであったり、WordPressが独自で吐き出すクラスとかですね。ライブラリごとにファイルを作ってあげると管理しやすくなると思います。