本文へスキップ
ナビゲーションメニュー 書籍を読む

mFLOCSS

CSS の設計判断を体系化する思考フレームワーク

「どの層に、なぜ書くか」——判断基準で、迷いを断つ。

書籍を読む¥3,000 / Zenn GitHub で spec / starter を見る（新しいタブで開く）

課題

CSS を書けば書くほど、どこに何を書いたか分からなくなっていく

原因は詳細度でも命名規則でもない。スタイルの置き場所を決める判断軸が無いことだ。手法を変えても、同じ迷いは繰り返される。

  • 詳細度の衝突

    !important が増え、修正すると別箇所が崩れる。セレクタの強さで押し切ろうとする、判断軸不在の規律頼みが行き着く先だ。

    #main .card .button.is-active { color: red !important; }

  • 値の散在とドリフト

    同じ色が複数ファイルに散らばり、たまたま近い別の値と見分けがつかない。値の置き場所を決める基準がなければ、生値はそこかしこに複製され続ける。

    .btn{color:#16a34a} .card{color:#16a34a} .tag{color:#15a241}

  • 層判断の属人化

    実装者ごとに置き場所が変わり、レビューのたびに同じ境界の議論を繰り返す。「これは Component か Project か」を決める基準がなければ、判断は結局、人によって割れる。

    この card は Component? Project? — 毎回割れる

解決

あとに宣言した層のクラスが、#id にも勝つ

優先順位は、セレクタの強さでなく層の宣言順で先に決まる。だから後に宣言した層のクラスが、詳細度に関係なく勝つ。

Before — 詳細度を手で積む 
.button {
  color: #1e40af;
}

/* ヒーロー内で勝たせたいので
   #id を足して詳細度を上げる */
#main .hero .button {
  color: #c2410c;
}

/* 次はもっと強いセレクタで勝たせる。
   結局、規律頼みの手作業に戻る */
After — 宣言順が詳細度を越える 
@layer token, reset, foundation, layout, component, project, animation, utility;

@layer component {
  /* #id で詳細度 1-1-0 */
  #main .button {
    color: #1e40af;
  }
}

@layer project {
  /* ただのクラス 0-1-0。
     でも後の層だから勝つ */
  .button {
    color: #c2410c;
  }
}

層の宣言順が、セレクタの詳細度より先に優先順位を決める。だから後の層のクラスは、#id で積み上げた詳細度にも順番で勝てる。詳細度を積み上げる競争から解放され、優先順位は「どの層に書くか」という宣言だけで決まる。この逆転が成立する条件はひとつ——すべてのスタイルを @layer の中に置くことだ。層の外に一行でも書けば、それがすべての層を上書きしてしまう。

正しい上書き（公開 API 経由）と各層の判断は 責任の層、手法比較は なぜ mFLOCSS か で。

構造

責任の層

各層は「何に答えるか」で定義される。@layer の宣言順がそのまま優先順位になり、下の層ほど強い。

@layer 宣言順 = 優先順位 — 下の層ほど強い ↓

Token
その値は、どこで一元管理するか
Reset
ブラウザ間の差を、どこまで無くすか
Foundation
要素の初期スタイルは、何を基準にするか
Layout
ページの骨格は、どう構成するか
Component
この部品は、別のサイトへそのまま持ち出せるか
Project
このパーツは、置く場所で決まるか
Animation
動きは、どこに集約するか
Utility
単一の上書きは、どこで最終保証するか

各層の判断基準は 責任の層の詳細 へ。

特長

mFLOCSS の設計原則

層の数が変わっても、変わらない設計の芯。

  • 判断基準の機械化

    「どの層に書くか」を、層ごとの判定テストで決められる。センスや経験に頼らず、問いに答えれば層が決まるから、置き場所に迷わない。

  • @layer による構造的制御

    詳細度の問題を、命名規則ではなくブラウザの仕組みで解決する。先制宣言 1 行で層の優先順位が確定する。

  • 関心の分離

    異なる問いに答えるスタイルを、異なる層に分ける。値の定義・初期化・配置・部品・サイト固有が混ざらない。

  • CSS の進化への追従

    層構成は CSS の進化に応じて適応させる余地を持つ。現在の層構成は、不変の教義ではない。

書籍

ルールでなく、判断力が身につく

書籍『そのFLOCSS、なぜそこに書いた？』の表紙

そのFLOCSS、なぜそこに書いた？

spec が「何を」を無料で示すのに対し、書籍は「なぜ・どう判断するか」を体系化する。各層の判断フローと境界の迷いを実例で追い、迷わない設計判断を手渡す。

¥3,000 Zenn / 実 13 章 + 付録 A〜D

購入後のアップデートは追加費用なし。

書籍を読む まだ迷っているなら、無料章（intro + ch1）から（新しいタブで開く）

エコシステム

仕様・実装・書籍でつながる

  • github.com/mflocss/spec

    spec（新しいタブで開く）

    設計判断の原典。MUST / SHOULD の原則で、判断基準を定義する。

    CC BY-SA 4.0
  • github.com/mflocss/starter

    starter（新しいタブで開く）

    LP（ランディングページ）向けの mFLOCSS リファレンス実装。Vite + Native CSS の軽量構成。

    MIT
  • zenn.dev/shunei/books

    書籍

    実 13 章 + 付録 A〜D。判断力を why / how から体系化する。

    ¥3,000
  • github.com/mflocss/wordpress-starter

    wordpress-starter

    mFLOCSS + WordPress の統合テーマ。

    近日公開

置き場所に迷わない CSS を、今日から

本書で、置き場所の判断基準が身につく。続きは GitHub と Zenn で。

実 13 章 + 付録 A〜D・購入後アップデート無料

判断基準を読む（¥3,000）

GitHub で仕様・実装を見る（新しいタブで開く） ／ X (@shunei_web) をフォロー（新しいタブで開く） ／ Zenn で記事を読む（新しいタブで開く）