「FLOCSS のテンプレートを使っているのに、気づけば CSS がぐちゃぐちゃになっている」——この相談をよく受けます。テンプレートが解決してくれるのは、ディレクトリ構成とファイルの置き場所だけ。実際のコーディングで迷うのは、もっと手前の判断です。
迷い 1
このスタイルは Component に書くのか、Project に書くのか？
迷い 2
ヘッダーのリンク色は、どの層で定義するのか？
迷い 3
ページ固有の微調整は、Project か Utility か？
同じテンプレートを使っているのに、人によってまったく違うコードが生まれるのは、判断基準が共有されていないからです。
/* はじめは素直なコード */ .button { background: #007bff; } /* 別のページで色を変えたくなった */ .header .button { background: #ff6600; } /* さらに別の箇所で、上書きが効かない… */ .sidebar .content .button { background: #28a745 !important; }
セレクタを重ねて詳細度を上げ、それでも足りなければ !important で対抗する。設計とは「未来の自分を助ける仕組み」です。いま動くかどうかではなく、半年後に修正しても壊れないかどうか。
!important
道具がどんなに進化しても、「どこに何を書くか」という設計判断は人間がやるしかない。
FLOCSS が CSS を層で分類し、命名規則で構造を示すという設計思想は正しい。しかし 2014 年の手段には構造的な限界があります。
課題 1
デザイントークンの管理場所がない。色やフォントの値がファイルに散在する。
課題 2
アニメーションのアクセシビリティ対応が各ファイルに散在し、対応漏れが起きる。
課題 3
詳細度の上書き問題は、命名規則だけでは防げない。
回答 1: Tokens + Theme
プリミティブ値とセマンティック値を分離する 2 つの新設層。ダークモードは Theme だけで切り替わる。
回答 2: Animation 層
アニメーションを分離し、prefers-reduced-motion 対応を一元管理。抜け漏れを仕組みで防ぐ。
prefers-reduced-motion
回答 3: @layer
ブラウザネイティブのカスケード制御。詳細度の問題を命名規則ではなくブラウザの仕組みで解決する。
層の数は設計変数であり、CSS の進化に応じて変わりうる。変わらないのは、以下の 4 つの原則です。
1. 関心の分離
異なる問いに答える層は分ける。Tokens は「この色の oklch 値はいくつか」、Theme は「プライマリカラーとしてどの色を使うか」——別の問いだから、分ける。
2. @layer による構造的制御
詳細度の問題を命名規則ではなく、ブラウザの仕組みで解決する。宣言順で優先度が決まるため、セレクタの詳細度を気にする必要がない。
3. 判断基準の明示
各層に「何を書くか」だけでなく「なぜその層か」の基準がある。判断の過程を共有することで、チームの CSS が一貫する。
4. CSS の進化への追従
層構成は CSS の進化に応じて適応させる設計余地を持つ。v1.0 では 8 層構成が最適解だが、将来は変わりうる。
mFLOCSS の設計判断を体系的に学べる技術書。 設計根拠の詳細、実案件の判断 Q&A、リファレンス実装のハンズオン。