標準化とスケーリング¶
プロジェクトの特性や規模に応じて、設計をスケールする方法について説明します。
アプローチ¶
想定するプロジェクトにおける 「最大規模のCSS分類」をあらかじめ用意し、プロジェクトによって拡張・縮小します。
全体像と導入方法で示した構成も、この最大構成を縮小した形の一つです。
最大構成の標準化¶
StrataCSSが標準とする最大構成は次の通りです。
レイヤー基点で概念構造を記載します。
* Base # プロジェクトの基底となるCSS
* Generic # ブラウザ初期スタイルの平滑化
* Library # 外部で作成された基底系や共通機能のCSS
* Resources # フォントやアニメーションなどの共通アットルールの定義
* Tokens # デザイントークンとして用いるCSSカスタムプロパティ
* Themes # テーマ切り替えに利用するスタイル(Tokens上書き用)
* Elements # プレーンHTML用のスタイル
* Layout # ヘッダー、フッターなどのページレイアウト要素
* Components # ボタンやカードなどの共通部品
* Pages # ページコンテンツ用のCSS
* Utilities # 単機能のCSS
* Print # 印刷用に上書きするCSS
それぞれの詳細については、 標準の名称と定義 で改めて説明します。
上記の記述順が、そのままレイヤー構造と上書きのルールになります。
仕様に落とし込むために、 @layer の宣言もネスト構造にします。
この構造をそのまま利用する場合、@layer は次のように記述します。
@layer
base.generic , base.library , base.resources , base.tokens , base.themes , base.elements,
layout,
components,
pages,
utilities,
print;
上記は、可読性を考慮して改行していますが、1行で記述しても問題ありません。
また、宣言に合わせて、エントリファイル（global.css / global.scss）の読み込み部分も対応させる必要があります。
@import "./global/base/generic/index.css" layer(base.generic);
@import "./global/base/library/index.css" layer(base.library);
/* 以降 `layout`、`components`… も同様 */
@layer base.generic {
@include meta.load-css("./global/base/generic");
}
@layer base.library {
@include meta.load-css("./global/base/library");
}
// 以降 `layout`、`components`… も同様
それぞれのディレクトリ内部の構成は、ファイルの管理しやすさにより適宜決定します。
スケーリング¶
前述の構造をもとに、プロジェクトによるスケーリングを検討します。
方法は、「不要なものは削除し、必要なものがあれば加える」ことです。
小規模サイトの例¶
数ページのコーポレートサイトの場合、前述の構成はオーバースペックになる可能性が高いでしょう。例えば、次のように構造を縮小できます。
* Base # プロジェクトの基底となるCSS
* Generic # ブラウザ初期スタイルの平滑化
* Resources # フォントやアニメーションなどの共通アットルールの定義
* Elements # プレーンHTML用のスタイル
* Layout # ヘッダー、フッターなどのページレイアウト要素
* Components # ボタンやカードなどの共通部品
* Pages # ページコンテンツ用のCSS
プロジェクト規模と照らし合わせ、実装上で不要と判断したものを削除した状態です。
さらに、ファイル管理視点では、Generic、Resources、Elements は、ディレクトリ化しなくとも、それぞれ1枚ずつのCSS（SCSS）で充分かもしれません。
要件に無い場合¶
印刷時のスタイル調整や、ライト・ダークなどのテーマ切り替えは要件に入らないこともあります。このような場合、対応する概念を丸ごと削除します。
将来追加するかもしれない、との方針で残すこともできますが、こちらは適宜ご判断ください。
追加ディレクトリが必要な場合¶
スライダーなどの外部でつくられたプラグインのCSSを、npm管理ではなく、ソースファイルのディレクトリでファイル管理しなければならないケースがあるかもしれません。
このようなケースにおいて、ファイル管理の視点から、CSSとJavaScriptを同じディレクトリに保存したい場合は、以下のように拡張しても問題ありません。
📁 src/
├─ 📁 styles/
│ ├─ 📁 abstracts/ # 共通利用する関数やMixin、Sass変数など
│ ├─ 📁 global/ # Global用のディレクトリ（全域用のCSSを管理）
│ └─ 📁 pages/ # Pages用のディレクトリ（ページ個別のCSSを管理）
├─ 📁 js/ # JavaScriptの管理ディレクトリ
└─ 📁 plugins/ # プラグイン用のCSSとJavaScriptの管理ディレクトリ
plugins/ は、他の命名でも問題ありません。
そして、内部に配置したプラグイン付属のCSSは、影響範囲や上書きしたいレイヤーに応じて、 global/ もしくは pages/ の該当ファイルから読み込むことになります。
この場合、見た目でスコープを把握する力は弱くなる（原則1から外れる）ため注意が必要です。
プロジェクトの成長と拡張¶
規模の違いはプロジェクト特性だけでなく、同じプロジェクトそのものが変化することがあります。
例えば、小規模なWebサイトに改修を加え、それに伴い構造が大きくなるケースです。
このようなケースでは、実際はリニューアルになることが多いかもしれませんが、デザインをそのままに拡張する場合でも、規模や要件追加に応じて必要なCSS分類を足す ことで、再設計のコストを抑えて拡張できます。
最大規模の標準を定めている場合、この枠を超えない限り同じ法則でスケーリングできます。
Pagesスコープの拡張¶
Pagesスコープの内部も、Globalと同じ考え方で拡張できます。
新たな概念を設けて仕様レベルで制御したい場合は、レイヤーを追加する、もしくはサブレイヤーとして定義できます。
例えば、特定のページ群（製品シリーズなど）で共通するCSSを pages-group として定義した場合は、次のようになります。
@layer base , layout , components , pages-group , pages , utilities , print;
その他の拡張と @layer の構造¶
その他のレイヤーも同様に拡張・変更できます。
どのように変更する場合でも、 @layer の定義とディレクトリ・ファイル構造は、サブレイヤーまで機械的に揃える必要がない点に注意してください。
例えば、layout/ の内部に header.scss と footer.scss を配置したからといって、必ずしも @layer layout.header {} , @layer layout.footer {} のように宣言する必要はありません。（※通常、サイトのヘッダーとフッターの上書き順は制御不要でしょう）
ディレクトリ・ファイル名と @layer の定義は、名前を一致させることで「関連性が見える状態」を維持できればよく、実際に@layer を定義するかどうかは、そのレイヤーが実装上で本当に必要かどうかで判断します。
Abstracts の構成¶
Abstracts は、Sass (SCSS) を利用する場合、もしくは将来 CSSカスタム関数とミックスイン が実用レベルになった際に利用しますが、内部構造はITCSSの定義を使います。
📁 styles/
├─ 📁 abstracts/ # GlobalとPagesで共通利用する関数やMixinなどの管理
│ ├─ settings/ # Sass変数の定義
│ └─ tools/ # Mixinと関数の管理
...
こちらも標準として定義しますが、必要に応じて変更してください。
次のステップ¶
分類の認識が一致していれば、構造が増減してもスケールしやすい状態を保てます。
次は、CSS分類とその他の名称も含め、StrataCSSの定義を説明します。