Gaji-Labo式、CSS の class 命名について

こんにちは、森田です。
先日、横田が Gaji-Labo式、破綻しにくいHTML+CSSコーディングルールの一部を紹介します という記事で弊社の HTML+CSS コーディングルールを紹介していたのですが、今回はその中の CSS の class 命名について掘り下げたいと思います。

主に使う class 命名について

命名はキャメルケース

.blockName {
  /* ... */
}

基本的にコンポーネントは2語を繋げたキャメルケースで class 名を指定します。

基本はBEM

.[blockName]__[elementName].[-modifier]

BEM を使い、Block と Element を __ で繋ぎます。modifierは - を接頭辞にして同じセレクタに付与します。
言語は Sass(SCSS) を使う前提です。

Element は Block に必ずネストする

.blockName {
  .blockName__elementName {
  }
}

これは命名ではなくルールなのですが、シングルセレクターや Sassの &__ 書きをしないで Element は Block に必ずネストすることにしています。

Element を単独で指定する必要はないとの考えからです。
これにより詳細度を上げて万が一class名が重複した場合にも影響がでない様に堅牢にしています。

modifier は rscss の Variants

.likeButton {
  &.-is-wide { /* ... */ }
  &.-is-short { /* ... */ }
  &.-is-disabled { /* ... */ }
}

状態を表すmodifier は BEMの -- で繋げるものはとてもクラス名が長くなるので  rscss.io の Variants を使い .- とします。
状態が分かりやすく、Sassを使っている場合は書きやすいです。

また、.-is 接頭辞を用い「○○ならば」といった意味の命名をし、状態がわかりやすいようにしています。

レイアウトに使う class の接頭辞

.l-header {
  /* ... */
}

.l-contents {
  /* ... */
}

.l-footer {
  /* ... */
}

共通ヘッダーやフッター、ナビゲージョンいわゆるガワのレイアウトは .l- 接頭辞を使います。
これにより一目でレイアウトの class なのがわかります。

ページに使う class の接頭辞

.p-top {
  /* ... */
}

.p-archive {
  .l-nav {
    /* ... */
  }
}

独自ページ（ページテンプレート）の class には .p- 接頭辞を使います。
これによりページ用に特別なスタイルを当てているルールセットなのがわかりやすいです。

WordPressの場合には body_class関数 で付与されたクラスにネストして指定するのも可です。

JSで使う class の接頭辞

<div class="l-layout js-hoge"></div>

JSでクラス名を取得する場合は .js- 接頭辞を使い、それ以外の class名をJSで使うことはありません。
逆に CSS でも .js- を指定することはありません。

CSS Modules でのパターン

CSS Modules を使う場合は基本的に上記ルールを使いますが、modifierは `.isHoge` の文法を使って書きます。

.[blockName]__[elementName].[isModifier]

これは .-hoge といったアンダースコアが先頭の class 名だと CSS Modules ではエラーになるからです。

このような場合は is 接頭辞はその他の命名では使わないなどのルールを設けます。

CSS in JS でのパターン

React や Vue.js で CSS in JS を使う場合は、上記のルールはあまり適用されません。
React であれば styled-components や emotion などのライブラリを使いますし、 Vue.js は Scoped CSS があります。
それによってコンポーネントごとにローカルスコープが働くので一意の命名などに拘る必要がないので、役割などのわかりやすい命名をすることが多いです。

ソースマップを使えばデバックも問題ないですしとても便利ですね。
Vue.js は data属性でスコープするので命名に少し気は使いますが。

参考にした CSS 設計思考

たくさんの素晴らしい CSS 設計思考 から弊社のやり方にマッチしたものを取り入れさせていただきました。

BEM（MindBEMding）

BEM（block、element、modifier）に基づく命名規則で、基本的な命名規則として使っています。

MindBEMding を初期は採用してのですが、現在 modifier は書き方が違うので、現在は BEM の Block と Element のルールを使っている形です。
しかし、記事が2013年なのはびっくりしました。もう7年も前なのに現役で使えてますね。それだけ理にかなった思想なのかもしれません。

rscss

Variants のルールを modifier で使っています。

この思想は rscss に限らず Chainable BEM modifiers などでも提唱されているので BEM や MindBEMding の modifier は書きづらいと思っている人は多いのかもしれません。

FLOCSS

FLOCSS（フロックス） はレイヤー構造や、それに準ずる命名の接頭辞などを参考にさせてもらいました。
また、Sass の Extend の禁止など、参考にした要素は沢山あります。

itcss

itscc はレイヤー構造および階層化を参考にさせてもらいました。
Inverted Triangle CSS という名前の通り、詳細度を逆三角形に可視化して考える方法はファイル構造にすると分かりやすく、詳細度に沿ったコーディングをすることができます。

コンポーネントの分類や、ファイル構成についても色々と試行錯誤していますので、また別の記事で紹介できればと考えております。

現在も進化中です

前提として未完成です。目まぐるしく変化するWEBの世界では完成は無いのかもしれません🤔

class 命名だけがうまくいけば破綻しない CSS 設計になる訳ではないので、命名も1つのファクタとしてよりより良い設計になるように考えています。

どしどし便利なエッセンスは取り入れていきたいですね。

最近は CSS設計完全ガイド という辞書のような厚さの本から色々と知見を得れたので弊社のコーディングルールに取り入れていければなと考えております。

Gaji-Laboブログ内には、他にもチーム開発でのWebフロントエンドについて取り上げた記事があります。
チーム開発のために必要なコーディングルールやスタイルガイド、コンポーネントの設計方法など、実践をもとにしたリアルなWebフロントエンド知見に興味がある方におすすめの記事シリーズを「チーム開発でのWebフロントエンド」としてまとめていますので、あわせてお読みいただけるとうれしいです。

関連リンク

• https://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/