構造を独自に設計する¶

FLOCSSとITCSSで見た手順を、ご自身のプロジェクトに適用するためのガイドです。

3つの原則を中心に、分類の名前、数、粒度などを設計します。

設計の基準¶

まず、設計の自由度と条件の境界を明確にします。

自由に決められるもの

3原則 （詳細）

FLOCSSとITCSSへの適用で示したとおり、分類の語彙は何でも構いません。
手法の「らしさ」を決める要素（語彙・命名・運用）は、すべて設計自由の側にあります。

この視点を持つと、既存手法を「従うもの」ではなく 「素材」として扱える ようになり、@layer を含めた独自の拡張を自分の基準で再設計しやすくなります。

設計した構造が原則通りかどうかは、次の3点で確認できます。

それぞれの確認の観点は次の通りです。

Scoping: 「このCSSはどこに効くか」が、ディレクトリを見るだけで分かる状態になっているか。
スコープ分離を採用しない場合は、意図があれば問題ありません。
Layering: 分類レベルの上書き順が「ファイルの記述順・読み込み順」という暗黙の状態に頼っていないか。
出力されるすべてのCSSが、いずれかのレイヤーに所属しているか（指定漏れの注意点）。
Aligning: 分類名を1つ聞けば、ディレクトリ名とレイヤー名を推測できる状態になっているか。

FLOCSSとITCSSのページで実演した手順を、一般形として整理します。

分類を書き出す
今使っている分類をそのまま列挙します。既存手法でも、チームの慣習でも、独自の分類でも構いません。
出力の有無で分ける
CSSを出力しない補助（変数・Mixin・関数）を分離します。これらは @layer を持たず、abstracts/ 相当のディレクトリで管理します。
上書き順に並べて宣言する
残った分類を「上書きされる側 → 上書きする側」の順に並べ、1行の @layer 宣言にします。宣言に現れない上書きルールを残さないことが要点です。
スコープ分離を採用するか判断する
全域／ページ個別の分離が、プロジェクトの規模と運用に見合うかを判断します。（詳細は後述）
名前を揃える
分類名から、ディレクトリ名と @layer 名を派生させます。

サブレイヤーまで機械的に揃える必要はありません。@layer を実際に定義するかどうかは、その階層の上書き制御が実装上必要かどうかで判断します。（標準化とスケーリングを参照）

原則1（Scoping）は任意の軸です。
採用するかどうかは、プロジェクトの規模と運用で判断します。

分離する場合の具体的な構成（Global / Pages のディレクトリ分割と読み込み）は、全体像と導入方法を参照してください。

この手順と視点から振り返ると、設計編の最大構成も「従うべき構成」ではなく、3原則を適用した参照実装の一例だと分かります。

また、導入ガイドの総括で述べた設計思想は、言い換えれば「独自手法の設計基盤」とも表現できます。

標準構成をそのまま使う、FLOCSSやITCSSの語彙で組む、独自の分類で組む。
どれを選んでも、既存手法の規則を一段上から眺め、設計材料として捉えることで、プロジェクトや現場に最適な仕組みを作りやすくなります。