Abstract
mFLOCSS は、CSS の記述を層に分類する思考フレームワークである。「このスタイルをどの層に書くか」という判断を体系化し、設計の一貫性と長期的な保守性を実現する。本仕様はその判断基準・命名規則・ファイル構成を厳密に定義する。
仕様書は、この自己定義に基づいて判断基準・命名規則・ファイル構成を条文の形で定めたものだ。以降の MUST / SHOULD / MAY は、すべてこの定義から導かれる。
要求レベル：MUST / SHOULD / MAY
RFC 2119 に基づく要求レベル。準拠とは、全 MUST / MUST NOT に違反しないことを指す。
- MUST
- 絶対的な要求。違反すると mFLOCSS 準拠を名乗れない。
@layerのカスケード構造を壊さないための、最小限の防御線に絞られている。 - MUST NOT
- 絶対的な禁止。違反すると mFLOCSS 準拠を名乗れない。
- SHOULD
- 推奨。正当な理由があれば逸脱でき、逸脱の理由はコメントか設計文書に残すのが望ましい。
- SHOULD NOT
- 非推奨。正当な理由があれば例外にできる。
- MAY
- 任意。プロジェクトの判断に委ねる。
仕様書の読み方
-
通読 vs 参照
最初に一度通読し、その後は実装時の参照辞書として使うと効率がよい。通読で層の全体像と不変原則を把握しておけば、実装中に「これはどの層か」と迷ったとき、該当箇所をピンポイントで引ける。
-
要求レベルの判断を学ぶ導線
MUST / SHOULD / MAY がなぜそう定められているかの背景は、書籍が判断の体系（ch2）と層判断の実例（ch4）で解説する。要求レベルの索引は付録 D にまとまっている。
spec リポへのリンク
-
GitHub spec リポ
mflocss/spec（新しいタブで開く） で全文を読める。
-
CC BY-SA 4.0 ライセンス
著作者表示と同一ライセンスでの配布を条件に、商用利用も改変もできる。mFLOCSS という名称で準拠を名乗るには、全 MUST / MUST NOT ルールへの準拠が条件になる。
FAQ
仕様書（spec）だけ読めば mFLOCSS を使えるか？
仕様書は「何が準拠で、何が違反か」を定義する。実装に必要な要件はすべて仕様書にある。ただし「なぜその判断基準なのか」「迷ったときにどう考えるか」は仕様書の範囲外。仕様書は判断の結論を、書籍は判断に至る思考を担う。実装規範は starter のコードで確認できる。3 つは役割が分かれており、すぐ書き始めたいなら仕様書 + starter、判断力を育てたいなら書籍を加える。
MUST / SHOULD / MAY はどう読み分ければいいか？
RFC 2119 に基づく要求レベル。MUST は絶対の要求で、違反すると mFLOCSS 準拠を名乗れない。MUST NOT は絶対の禁止。SHOULD は推奨で、正当な理由があれば逸脱してよい（逸脱理由をコメントか設計文書に残すことが推奨される）。MAY は任意。準拠とは全 MUST / MUST NOT に違反しないこと。SHOULD を守るほど設計の一貫性は上がるが、守らなくても非準拠にはならない。
なぜ MUST は少なく、設計判断の多くが SHOULD なのか？
MUST は @layer のカスケード構造を壊さないための最小限の防御線に絞っているため。層間の依存方向（下位層から上位層を参照しない）や Utility 層の最終上書き保証など、破ると設計全体が崩れるルールだけを MUST にしている。一方、どの層にどのパーツを置くかといった設計判断の品質は SHOULD で推奨する。判断の自由度を残しつつ、構造の安全だけは絶対に守る、という線引き。
仕様書は通読すべきか、必要なときに参照すれば足りるか？
最初に一度通読し、その後は実装時の参照辞書として使うのが効率的。通読で「層の全体像」と「不変原則」を頭に入れておくと、実装中に「これはどの層か」と迷ったとき該当章をピンポイントで引ける。各層の責任と検証問い（Portability Test など）は §5 にまとまっており、判断に迷うたびに参照する設計になっている。要求レベル一覧は §2 にある。
spec のライセンスは何か。商用利用や改変はできるか？
CC BY-SA 4.0。これは spec という文書そのものを改変・再配布する場合のライセンスで、著作者表示と同一ライセンスでの配布を条件に、商用利用も改変もできる。なお mFLOCSS の設計手法を自分の CSS プロジェクトで実装するだけなら、このライセンス条件は適用されない（仕様文書を配布していないため、設計手法の利用は自由）。spec 文書を改変して派生フレームワークを公開する場合は、「mFLOCSS」とは異なる名称を使い、CC BY-SA 4.0 の条件（著作者表示・継承）に従う。「mFLOCSS」の名称で準拠を表明するには、全 MUST / MUST NOT ルールに準拠していることが条件になる。
仕様書の「なぜそうなっているか」を深く知りたい場合は？
書籍が判断の背景を解説する。仕様書は MUST / SHOULD / MAY の結論を示すが、その結論に至った設計判断の過程は書籍が担う。仕様書で要件を確認し、書籍で判断の根拠を学ぶ、という分業になっている。
仕様書はどのくらいの頻度で更新されるか。バージョンの読み方は？
セマンティックバージョニングに準拠している。メジャーは層の追加・削除・統合や MUST / MUST NOT の変更、マイナーは SHOULD / MAY の変更や参考情報の変更、パッチは誤記修正など要求レベルに影響しない変更。v1.0 確定後は仕様を安定させる方針で、頻繁な破壊的変更は行わない。変更履歴は spec リポの CHANGELOG（新しいタブで開く） で追える。