採用判断
なぜ mFLOCSS か
このスタイル、Component か Project か。書くたびに迷い、レビューのたびに同じ議論を繰り返していないだろうか。
mFLOCSS は、FLOCSS を出発点に、この判断を層ごとのテストで機械化する思考フレームワークだ。詳細度は命名規則ではなく、@layer というブラウザの仕組みに委ねる。
CSS の進化が変えた前提
著者が Web 制作の学習過程から積み上げてきた開発環境を、チーム開発に持ち込んだとき、メンバーから「使いやすい」「層判断や命名規則の判断軸が明確で迷わない」という評価をもらった。ただし当時、その判断軸はまだ仕組みではなく規律で支えられていた。FLOCSS という優れた出発点があってこそ辿り着いた実感であり、同時に FLOCSS だけでは解決しきれない迷いも見えてきた。
-
値の一元管理が、言語の機能になった
Custom Properties の登場で、色や余白の値は変数として一元管理できるようになった。FLOCSS が生まれた時代にこの道具はなく、仕様にも値の置き場所の定義がない。だから値はコンポーネントとプロジェクトのファイルに分散していく。mFLOCSS は Token 層を立てて、この置き場所に層で答えた。
-
動きは、分離して集約できるようになった
prefers-reduced-motionへの対応も含め、動きの定義は一箇所に集めて管理できる時代になった。keyframes の置き場所について FLOCSS は基準を持たないため、プロジェクトが育つほど散在していく。mFLOCSS は Animation 層を新設して、集約先を構造で決めた。 -
詳細度は、宣言順で解けるようになった
@layerの登場で、優先順位はセレクタの強さではなく層の宣言順で決められるようになった。FLOCSS は境界を命名の規律と読み込み順への注意で保つ設計で、規律が守られている間は機能するが、チームが増えるほど詳細度の押し合いに戻っていく。mFLOCSS はこの制御を、ブラウザの仕組みに肩代わりさせた。
他手法との違い
mFLOCSS がどの手法の代替で、どの手法と共存できるかを整理する。
-
FLOCSS との違い
mFLOCSS は、FLOCSS の層分離とプレフィックス思想を引き継ぎながら、Object 層に同居していた Component・Project・Utility をトップレベルの層に引き上げ、値の一元管理を担う Token 層と、動きを集約する Animation 層を加えた。そして詳細度の調整を、命名規則ではなく
@layerの宣言順という、ブラウザの仕組みに委ねる。FLOCSS の代替ではなく、その先の設計判断まで体系化した進化形である。 -
Tailwind CSS との違い
Tailwind は「何をどう書くか」を効率化するユーティリティ群であり、mFLOCSS は「何をどこに書くか」を決める判断フレームワークだ。答えている痛みが違うため、競合しない。Tailwind を使うプロジェクトでも独自の CSS を書く場面は必ず残り、そのとき「この値はトークンか」「このパーツは再利用するか」という判断は残り続ける。
-
BEM のみ運用との違い
BEM は命名規則によってブロックと要素の関係を表現する。だが、あるスタイルをどのブロックに属させるか、どこで新しいブロックに切り出すかという境界の判断そのものは、BEM の記法の外にある。mFLOCSS は BEM の
Block__Element記法を引き継ぎつつ、その境界を判断テストで決める判断軸を足す。 -
CUBE CSS との違い
CUBE CSS も責任の分離を志向する設計手法であり、思想の重なる部分がある。mFLOCSS は各層の境界を、判断テストという問いの形で機械的に判断できるようにしている点が異なる。
-
Open Props との違い
Open Props は Custom Property でデザイントークンを提供するライブラリで、mFLOCSS とは競合しない。mFLOCSS の Token 層が値をどこで定義するかを決める一方、Open Props はその値の供給源になり得る。組み合わせて使える関係だ。
Tailwind で十分への 4 回答
-
回答1: 答えている痛みが違う
「Tailwind があれば十分では」という声はよく聞く。答えは、両者が答えている痛みが違うということだ。Tailwind はクラス名を考える手間をなくすユーティリティ群であり、mFLOCSS はそのスタイルをどこに書くかの判断を体系化する基準だ。競合ではなく、積み重ねられる関係にある。
-
回答2: 置き場所の判断は Tailwind の中にもある
Tailwind の中でも、この値を theme に置くか、その場のユーティリティで済ますか、繰り返すパターンを部品に切り出すか、という置き場所の判断はある。そして Tailwind だけでプロジェクトが完結することは少ない。独自のコンポーネントスタイルやプロジェクト固有のレイアウトなど、カスタム CSS を書く場面は必ず訪れる。そのとき「この値はどこで一元管理するか」「このスタイルは別のサイトへ持ち出せるか」という判断が要る。mFLOCSS はその判断の受け皿になる。
-
回答3: コンポーネント指向との両立
React や Vue のようなコンポーネント指向のフレームワークと組み合わせても、層の判断は残る。CSS Modules や CSS-in-JS でスコープを切っていても、「このスタイルはコンポーネント自身の責任か、置く場所によって変わるプロジェクト固有の責任か」という問いは消えない。mFLOCSS の判断テストは、実装手段を問わず適用できる。
-
回答4: AI が CSS を書く時代
AI に CSS を書かせる場面が増えている。だが AI は「このスタイルをどこに書くか」を正しく判断できるとは限らない。判断基準を明文化しておけば、AI が生成したコードをその基準で検証し、準拠しているかを確かめられるようになる。
4 つの不変原則
- 関心の分離 — 異なる問いに答えるスタイルは異なる層に分離する
@layerによる構造的制御 — 詳細度の問題を命名規則ではなくブラウザの仕組みで解決する- 判断基準の明示 — 各層に「何を書くか」の明確な判断基準がある
- CSS の進化への追従 — 層構成は CSS の進化に応じて適応させる設計余地を持つ
-
原則1 補足
値の定義、初期化、配置、部品、サイト固有の見た目は、それぞれ異なる問いに答えている。答える問いが違えば、書く層も違う。
-
原則2 補足
詳細度を積み上げる代わりに、層の宣言順で優先順位を先に決めておく。
-
原則3 補足
各層は判断テストという形で、そこに書くべきかどうかを判断できる。
-
原則4 補足
現在の層構成は最終形ではない。CSS の進化に応じて見直す余地を持つ。
FAQ
Tailwind CSS を使えば CSS 設計はもう不要では？
答えている痛みが違う。Tailwind CSS は「クラス名を考える手間」をなくすユーティリティ群、mFLOCSS は「どこに書くかの判断」を体系化する設計フレームワーク。Tailwind の中でも値やパターンの置き場所の判断はあり、カスタム CSS を書く場面では「この色はトークンか、このパーツは再利用するか」という層の判断が残る。両者は競合せず、Tailwind を使いながら mFLOCSS の判断基準を併せて持てる。
mFLOCSS は FLOCSS と何が違うのか？
FLOCSS が体系化していなかった 3 点を mFLOCSS は明確にした。デザイントークンの置き場、アニメーションの集約先、そして詳細度の制御方法。FLOCSS は詳細度を命名規則で管理するが、mFLOCSS は @layer でブラウザの仕組みに委ねる。FLOCSS の層分離・プレフィックス・Component と Project の区別はそのまま継承しているため、FLOCSS 経験者は判断基準の追加として学べる。
FLOCSS から移行するコストは大きいか？
既存の CSS を書き換える必要はない。@layer は後付けできるため、第一段階は既存プロジェクトに @layer 宣言を 1 行追加するだけ。第二段階で新しく作るパーツから層に分けて書き、第三段階で既存のコードを触る機会のあるところから層へ移す。この三段階は はじめかた にまとめた。どの段階で止めてもサイトが壊れないから、一度に全部やる必要はない。
@layer（Cascade Layers）はどのブラウザで使えるか？
2022 年に Chrome / Firefox / Safari / Edge の全主要ブラウザで対応済み。Baseline に入っており、IE 以外は実務で問題にならない。@layer は CSS 標準機能（CSS Cascading and Inheritance Level 5）であり、Sass などのビルドツールに依存しない。今から学んでも陳腐化しない技術基盤の上に mFLOCSS は立っている。
Sass を使い続けないと mFLOCSS は書けないのか？
Native CSS だけで書ける。@layer によるカスケード制御、Custom Property によるトークン管理、ネスト構文はいずれもブラウザがネイティブ対応した。Sass が担っていた役割を CSS 自身が吸収したため、Sass なしの Native CSS だけで mFLOCSS を運用できる（starter は Vite ベースの軽量構成でバンドル・最適化のみ担い、Sass の前処理には依存しない）。Sass を併用したいプロジェクトでは @layer 内に Sass を共存させる移行パスも取れる。
詳細度バトル（!important の応酬）は本当に解決するのか？
する。詳細度バトルは「後から書いたスタイルが効かず、#main .btn のようにセレクタを強くして勝とうとする」ことで起きる。@layer は詳細度ではなく宣言順でカスケードを決めるため、@layer 内のスタイルはセレクタの強さに関係なく層の順序で優先される。Utility 層を最後に宣言すれば、Utility が常に最優先になることが構造的に保証される。セレクタの詳細度を競うために !important を持ち出す理由がなくなる（Utility 層自体は単一目的の上書きに !important を付与するが、それは詳細度バトルとは別の、層順を超えた最終上書きの保証）。
Open Props や CUBE CSS と併用できるか？
Open Props とは併用できる。Open Props は CSS Custom Property でデザイントークンを提供するライブラリで、mFLOCSS の Token 層の値の供給源として使える。CUBE CSS は「Composition / Utility / Block / Exception」という別の分類軸を持つ設計手法で、mFLOCSS と思想が重なる部分があるため、どちらの判断基準を主にするかを決めて使うことになる。mFLOCSS はトークンの供給を外部ライブラリに委ねても成立する設計。
チームに導入するとき、学習コストはどのくらいか？
判断基準を覚えるのが中心で、新しい記法はほとんどない。BEM の Block__Element 記法を土台にしているため、覚えるのは「どの層に書くか」を決める検証問い（別のサイトに持っていけるか、配置・寸法・空間の確保か）と、バリエーションを表す .-modifier の形だけ。仕様書で要件を確認し、starter の実装を規範として真似て、書籍で判断の背景を学ぶという 3 つの教材が揃っている。書籍は無料章（intro + ch1）で全体像をつかめるため、導入判断はそこで済ませられる。