開発体制に合わせたCSS設計

この記事は、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を使っているサイト例

• Qiita

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設計も変わってくる）

自社サービス（継続的な改修）か受託サイト（一度きりの制作）か

• 自社サービス：ルール多
• 受託サイト：ルール少

実装者の権限レベルの差

• フラット：ルール少
• 上下関係あり：ルール多

以上のことを総合し、これらがどう変動していくか

選定や設計で大事なこと