この記事は、HTML5 Conference 2018で行なった登壇内容を加筆修正したものです。
CSS設計とは
CSS設計
- 設計思想(コンポーネント設計)
- 命名規則
等々
CSS設計
- Predictable 予測しやすい
- Reusable 再利用しやすい
- Maintainable 保守しやすい
- Scalable 拡張しやすい
参考:https://philipwalton.com/articles/css-architecture/
CSS設計の必要性
コスト削減
- 実装者の単価を減らせる
- 実装工数を減らせる
- 既存のコンポーネントを使うことで工数を減らせる
- デグレが起きる確率が減り改修工数を減らせる
- 部分的な改修を行うことで並行して実装ができる
観測した限りのCSS設計
CSS設計
OOCSS
- オブジェクト指向
- Bootstrap
BEM(MindBEMding)
- シングルクラスにする命名規則
SMACSS
- OOCSSやBEMなどから影響を受けている
- Base、Layout、Module、State、Themeのカテゴリーから構成される
MCSS(Multilayer CSS)
- OOCSSやBEMなどから影響を受けている
- Foundation、Base、Project、Cosmeticのレイヤーから構成される
SUIT CSS
- コンポーネント指向
FLOCSS
- OOCSS、SMACSS、BEM、SuitCSS、MCSSなどから影響を受けている
ECSS(Enduring CSS)
- デザインを再利用しない(CSSコードの重複を許す)ため、変更や削除に強い
AMCSS
- `[am-Button] { /* base button styles */ }` のように属性を使った指定方法
RSCSS
- 子セレクタ(>)を使ってすっきり書く
ITCSS
- 詳細度の広い順に階層構造になっている
FLOU
- FLOCSSに疲れた人が使うやつ
APB CSS
- Atomic Designを取り入れたCSS設計
- 最小単位から構成していく
UIコンポーネント設計
- Atomic Design
JavaScriptを使ってカプセル化
- Web Components
- CSS in JS
等々
よく使われているもの
- BEM
- OOCSS
- SMACSS
参考:https://ashleynolan.co.uk/blog/frontend-tooling-survey-2018-results
Qiitaの記事が多かったもの
- BEM(22件)
- FLOCSS(13件)
※件数:2018年11月23日現在、2017年以降、Qiitaの記事タイトル
特徴別
- ECSS(コンポーネントを再利用しない)
- RSCSS(ルールが少ない)
CSS設計実例
FLOCSSとは
- Foundation、Layout、Objectのレイヤーと、Objectの子レイヤーで構成される
├─ Foundation
├─ Layout
└─ Object
├─ Component
├─ Project
└─ Utility
FLOCSSの書き方

HTML
<div class="c-media p-profile">
<img src="hoge.png" class="c-media__icon c-media__icon--profile">
<div class="c-media__body">Lorem ipsum ...</div>
</div>
CSS
.c-media {
width: 80%;
border: 1px solid #ccc;
padding: 1vw;
display: flex;
align-items: flex-start;
}
.c-media__icon {
border-radius: 50%;
}
.c-media__icon--profile {
width: 10vw;
height: auto;
}
.c-media__body {
margin-left: 2vw;
}
.p-profile {
padding: 2vw;
}
</style>
FLOCSSを使っているサイト例
ECSSとは
- デザインを再利用しない(CSSコードの重複を許す)ため、変更や削除に強い
ECSSの書き方

書き方
namespace-Module_ChildNode-variant
HTML
<div class="home-Profile">
<img src="hoge.png" class="home-Profile_Icon">
<div class="home-Profile_Body">Lorem ipsum ...</div>
</div>
CSS
.home-Profile {
width: 80%;
border: 1px solid #ccc;
padding: 1vw;
display: flex;
align-items: flex-start;
padding: 2vw;
}
.home-Profile_Icon {
border-radius: 50%;
width: 10vw;
height: auto;
}
.home-Profile_Body {
margin-left: 2vw;
}
ECSSを使っているサイト例
RSCSSとは
- 子セレクタ
>
を使うことですっきりと記述できる - 比較的ルールがゆるい
- フレームワークというよりアイディア集
RSCSSの書き方

HTML
<div class="media-area -profile">
<img src="hoge.png" class="mediaicon -profile">
<div class="mediabody">Lorem ipsum ...</div>
</div>
CSS
.media-area {
width: 80%; // widthのようなレイアウトを決めるものは記述しないが今回は許容している
border: 1px solid #ccc;
padding: 1vw;
display: flex;
align-items: flex-start;
}
.media-area.-profile {
padding: 2vw;
}
.media-area > .mediaicon {
border-radius: 50%;
}
.media-area > .mediaicon.-profile {
width: 10vw;
height: auto;
}
.media-area > .mediabody {
margin-left: 2vw;
}
RSCSSを使っているサイト例
考慮しなければいけない開発体制
複雑なCSS設計あるある
- 誰もルールを覚えていない
- 誰も正解を知らない
- スタイルガイドにあった気がするんだけどどこだっけ……
- コンポーネントをどのカテゴリに含めていいかわからない
- エンジニアが消しちゃいけない要素やclassを消す
- ビジュアルデザイナーがちゃんとコンポーネントを使ってくれない
- サイトすべてがいつまで経っても置き換わらない
それぞれの位置付け

ルールが多いということは
- 自由度が少ない
- デザインに制限がされる
- プログラムに制限がされる
- 高度なことが求められる(人件費、工数の増加)
- コードチェックに時間がかかる
- 複雑で悩んでしまう(別解釈が生まれる)
- すぐに思い出せない
- 既存システムに導入しにくい
開発体制から見るCSS設計選定基準(目的が達成できるか)
実装者の人数
- 多い:ルール多
実装者がコーディングに関わる時間的割合
- 少ない:ルール少
実装者のスキル
- 詳しい人がいる場合:ルール多
- 詳しい人がいない場合:ルール少
- 詳しい人だけしかいない場合(頭を使う人と、単純作業をする人とが出る):?
改修の頻度
- 少ない:ルール少
- 多い:ルール多
社内政治力があるか(コーダー、エンジニア、デザイナー、ディレクターなどがきちんとコミュニケーションが取れているか)
- 取れていない:ルール少、そもそもちゃんとコミュニケーションを取るべきでは
- 取れている:話し合いで決定
既存サイトの構成から見るCSS設計選定基準(目的が達成できるか)
コンポーネントやデザインの種類の多さ
- 少ない:ルール少
- 多い:ルール多、そもそもコンポーネントの種類を減らすべきでは
サイトの規模
- 小さい:ルール少
- 大きい:ルール多
- 大きすぎる:?(サイトの中の各機能や各サービスごとに対応)
サイトの今後のスケール
- 大きくなる:依存度低
エンジニア(JavaScript部分)との依存度
- 低い:ルール多
- 高い:ルール少(JavaScriptのフレームワークにもよってCSS設計も変わってくる)
自社サービス(継続的な改修)か受託サイト(一度きりの制作)か
- 自社サービス:ルール多
- 受託サイト:ルール少
実装者の権限レベルの差
- フラット:ルール少
- 上下関係あり:ルール多
以上のことを総合し、これらがどう変動していくか
選定や設計で大事なこと
サイトの特性だいじ
- サイトの規模
- 今後のスケール
開発体制だいじ
- 実装者のスキルが合っているか
- コミュニケーションが取れているか
社内政治力だいじ
- CSS設計はビジュアルデザインを叶えるための道具ではない
- CSS設計をするとデザインやプログラムや開発体制がある程度は制限される
- 仕方ない
- 必要であることを理解してもらう
- 採用方針にまで影響がある
選定後にも設計の変更だいじ
- プロジェクトで独自ルールを作る
- FLOCSSを選びつつもRSCSSに寄せたり、ECSSに寄せたりしたっていい