CSSのカスケードレイヤーを前提とした管理手法の話です。
AIコーディング時代に「心の安寧」を求めて作成したもので、ドキュメントの紹介を兼ねた投稿です。
概要
何を作ったか
Webサイト制作における、@layer を前提としたCSSの管理方法です。
既存手法の置き換えを強要することなく、CSSの住所決めと @layer の導入に特化しています。
ドキュメントでは FLOCSS と ITCSS を例に、@layer の導入方法（置き換え強要ではないこと）についても触れていますが、この投稿は紹介用のため、組み立て部分のみを抜き出して記載します。
なぜ作ったか
昨今、ネットや海外記事ではSPA系の話題が主流ですが、少なくとも自分の身の回りでは慣例的なWebサイトの制作はまだまだあります。
この分野で @layer 込みで確立された設計手法が見つけられなかったのと、「AIコーディング＋協業」を模索するにあたり、汎用的な枠組みがほしかった。というのが理由です。
また、冒頭で少し書きましたが、AIにCSSを書かせたときに「紳士協定」で上書きのルールを守らせるのではなく、仕様で強制して心の安寧を得たかった、というのも大きいです。
内容
さて、内容ですが、主張は 「CSS分類を定義して、ディレクトリ名とレイヤー名にも同じ名前をつけて管理しましょう」という話です。
クラス命名規則やスタイリングの規則は対象外（疎結合）です。
いきなり本題ですが、組み立て部分を図解すると以下の1枚の絵になります。
ここで「また自分定義の分類？」と思われたくないので先回りするのですが、中央レーンのCSS分類は 「標準」であって「規則」ではないです。ここは制作者や案件それぞれで最適解が変わるので、「既存手法、もしくは使い慣れた語彙で自由に組み立ててください」のエリアです。
ここでは「標準」として定めたものを例に進めます。流れとしては、中央レーンの（1）から、左右の（2）に展開し、（3）でCSSを書いてHTMLに読み込みます。
既存手法と違うところ
既存手法と違うところがあるとすれば、「全域用CSS ＋ ページ個別CSS」という、旧来からおこなわれてきた慣例的な手法を、原則（土台となる基本的な考え方）にしている点です。
あともうひとつは、概念・ディレクトリ・レイヤーを同じ言葉で揃えること。設計者であれば同じ着地点になりそうなものですが、こちらも原則化しています。
つまり何がしたいのか
上記のフロー図を簡潔にまとめると、以下のようになります。
制作者間で定義の認識を一致させた上で、ユビキタス言語的に「同じ言葉を使いましょう（そうすると、人もAIも予測しやすいよね）」というお話です。
実際のところ、よく引き合いに出される「予測しやすさ」は、認識合わせと文字列一致で大体なんとかなるものだと思っています。
CSSの記述
続けて、前述の全域用（Global）のCSSと、ページ個別（Pages）のCSS記述方法について説明します。
先日、せきゆおう（@wurst_design） さんが、Sass利用のアンケートを投稿されていました。結果を見て、ここでのサンプルコードはSassをメインに記載してみます。
全域用のCSS（global.scss / 慣例ではstyle.scss）
まず、全域用（Global）のCSSから。
全域用のCSSは、主にヘッダーやフッター、全ページ共用のコンポーネントなどを定義する想定です。
ファイルの先頭でCSSレイヤーを宣言し、続けて、サブディレクトリのCSSをまとめて宣言済みのレイヤーに所属させます。
@use を @layer でラップするとコンパイルエラーになりますが、@include meta.load-css であればコンパイルが通ります。
@charset "utf-8";
@use "sass:meta";
// レイヤーの宣言
// --------------------------------------------------
@layer base , layout , components , pages , utilities , print;
// 各レイヤーの `_index.scss` を読み込み
// --------------------------------------------------
@layer base {
@include meta.load-css("./global/base/");
}
@layer layout {
@include meta.load-css("./global/layout/");
}
@layer components {
@include meta.load-css("./global/components/");
}
@layer utilities {
@include meta.load-css("./global/utilities/");
}
@layer print {
@include meta.load-css("./global/print/");
}
// ※ pages はここでは宣言のみ。中身は後述のページ個別CSS側で埋めます
Sassの @import は廃止される予定なので、使わない前提の実装です。
ただ、@include meta.load-css は、読み込んだSassの公開メンバーが使えません。最上位レベルのエントリファイルでSass変数を使ってスタイリングすることは考えにくいですが、念のため。（※ 詳細については meta.load-css の利用方法 にも書いてます）
ページ個別のCSS
次に、ページ個別（Pages）のCSSについて。
ページ個別のCSSは、そのページ限定のコンテンツブロックのスタイリングを想定しています。
前述の全域用とは異なり、各CSSファイルそれぞれに @layer を記述します。
@charset "utf-8";
@layer pages {
.object-1 { ... }
.object-2 { ... }
.object-3 { ... }
}
これで、最初の図解で示した、全てのレイヤーの宣言が埋まった形です。
HTMLでの読み込み
あとは、2つのファイルを順にHTMLに読み込みます。
<!-- 全域用のCSS -->
<link rel="stylesheet" href="./assets/css/global.css">
<!-- ページ個別のCSS -->
<link rel="stylesheet" href="./assets/css/pages/home.css">
最初に読み込んだCSSの先頭で @layer を宣言しているため、後続する「ページ個別CSS」のレイヤー（pages）は、最初に宣言した位置で固定されます。
これで、意図した通りのレイヤー構造になります。
この先の話とドキュメント紹介
アプローチについては以上です。
実際はこの組み立てをもとにスケールさせる「考え方」がメインで、ある意味「標準」を元にした上記の流れは参照実装のようなものと言えます。
特に発明のようなものはありませんが、もしご興味があればドキュメントの方も覗いてみてください。
以下、観点別で内容を紹介します。
コンテンツ抜粋
- 原則って書いてるけど何？ → 考え方と原則
- どうやってスケールする？ → 標準化とスケーリング
-
@layerの落とし穴は？ → @layer 導入時の注意点 / CDN利用時の注意 - FLOCSSへ
@layerを適用するには？ → FLOCSSへの適用 - 独自に設計するには？ → 構造を独自に設計する
- AIとの認識合わせは？（参考） → AI利用
※ 本投稿の詳細版は「全体像と導入方法」に置いてます。
さいごに
総じて、 @layer を上手く使うにはどうしたらいい？どうやったら設計の助けになる？といった視点で設計手法を整理したものです。
CSS設計が語られ尽くされた感がある今の時代に、既存手法を再編成して「●●CSS」として出すこと自体、自分でも「どうなんだろう…」という疑問を持ちつつの投稿ですが、ファイル・ディレクトリ管理まで踏み込んで体系化した @layer 関連の公開ドキュメントが見つけられなかったので、外向けに作成してみたというお話でした。
現場では、Webサイト制作の文脈やCMS案件が近い将来に全部無くなるとは考えにくいと思います。今後の動向は分かりませんが、これからそのような現場に従事する方々や、業務標準化で悩んでおられる方の参考になればいいな、との気持ちもあります。
ドキュメントの記載内容は一応裏取りしていますが、もし何かツッコミどころがあれば教えていただけると嬉しいです。