#前提
そもそも理想的なcssとはどうあるべきか？
１・予測可能である
予測可能なcssは、期待した場所に期待した通りの振る舞いをする。何が起きるかわからないcssではいけない。
２・再利用可能である
再利用可能なCSSは、ある場所で解決した動作を、再びコーディングすることなく別の場所で用いることができる。一つのルールで「こんな見た目でこんな配置、こんな風に動く」と定めてしまうことは再利用できる可能性を奪う。できるだけ抽象的に、機能を分離する必要がある。
３・維持できる
維持できる（＝保守性の高い）CSSは、新たな機能を追加しても、既存の機能を阻害しない。新しく機能を追加した際に、それが別の機能を阻害してしまっては、都度見直しが必要なる。作業工数が増えてしまう（非効率的）
４・拡張性がある
拡張性があるCSSは、多くの開発者の手によって拡張されていく際に、管理コストを下げます。
例えば、学習コストが低いことで、書いた本人でなくても修正が可能である必要がある。
FLOCSSを使用するメリット
上記の４つの理想に限りなく近づけたのがFLOCSSで、FLOCSSはHiroki taniによって考案された。
使用するメリットしては
・ドキュメントが日本語
国産のCSS設計思想なので、ドキュメントが充実している。
実際に考案したHiroki taniさんのgithubにドキュメントが乗っている。
➡︎FLOCSSドキュメント
・プロジェクト固有パーツをComponentと別に分けておける
#FLOCSSの基本構成
FLOCSSは３つのレイヤー、そして３つの子レイヤーで構成されている。
- Foundation
- Layout
- Object
- Component
- Project
- Utility
#FLOCSSの各レイヤーについて
##Foundation
Reset.cssやNormalize.cssなどを用いたブラウザのデフォルトスタイルの初期化や、プロジェクトにおける基本的なスタイルを定義する。 ページの下地としての全体の背景や、基本的なタイポグラフィなどが該当する。
例 base.scss
##Layout
ページを構成するヘッダーやメインのコンテンツエリア、サイドバーやフッターといったプロジェクト共通のコンテイナーブロックのスタイルを定義する。基本的にはページ単位の存在になるので、idセレクタを使うことも可能。
例 header.scss
##Object
プロジェクトに置ける繰り返されるビジュアルパターンを全て定義する。また下記の３つの子レイヤーをもつ。
1 Component
再利用できるパターンとして小さな単位のモジュールを定義する。最低限の機能を持ったものとして定義されるべきであり、それ自体が固有の幅や色などの特色を持つことを避ける。
例 button.scss
2 Project
プロジェクト固有のパターンであり、いくつかのcomponentと、それに該当しない要素によって構成されるものを定義します。例えば、記事一覧や、ユーザープロフィール、画像ギャラリーなどが該当する。
3 Utility
componentとprojectレイヤーのObjectのモディファイアで完結することが難しい、適切ではない、わずかなスタイルの調整のための便利クラスなどを定義する。
※モディファイアとは
BlockやElementに対するフラグのようなもので 見た目や状態(disabledやfocus、highlightedやsize-bigなど)の情報を付け加える。
#FLOCSSの命名規則
FLOCSSでは、MindBEMding を使用します。
これは、BEMという設計思想を元にした命名規則です。
モジュールをBlock、Element、Modifierにわけて考え、それぞれを.Block__Element--Modifierのようにつなげて記述する。
接頭辞（プレフィクス）をつける
FLOCSSでは、クラスがどのレイヤー属しているかによってそれぞれプレフィックスをつける。
これにより、クラスがどのような役割を持っているのかわかるため、「予測しやすく」 なる。
また、予測しやすいことは開発者にとっても意図がわかりやすいため 「拡張しやすい」 とも言える。
レイヤーとそれに対応する接頭辞は下記の通り
Component : .c-
Project : .p-
Utility : .u-
さらに、状態を表すクラスの接頭辞として.is-を使う。