Gaji-Labo式、破綻しにくいHTML+CSSコーディングルールの一部を紹介します

こんにちは、Gaji-Labo 横田です。受託でHTML+CSSコンポーネント・JavaScript・Rails view等フロントエンド開発をお手伝いしています。

プロジェクトの開発スタート時には、開発環境の用意など準備するものがいろいろあります。プロジェクトの特性に合わせて用意するコーディングルールは毎回異なりますが、複数人で使って破綻しにくく、既存のルールにも取り込みやすい、Gaji-Laboのスタンダードとも言えるHTML+CSSのコーディングルールがあります。その一部を簡単に紹介します。

classの命名

BEM（MindBEMding）を基本としていますが、modifier名のみ改変しています。本来 BEM では .block__element--modifier となりますが、

• class 名が長くなりがち
• element をまたいで共通の modifier が必要なときに class 名の組み合わせが爆発することがある

これらを解消するために modifier だけ rscss.io の Variants のルールを利用しています。

div.block
 div.block__element.-modifier

.block {
 .block__element {
  &.-modifier {...}
 }

HTMLもCSSもmodifierの見通しがよくなって状態がわかりやすいです。人的ミスが減って開発スピードがあがると実感しています。

CSS Selector の指定に変則ルールをもうける

コンポーネント内で完結し、且つセマンティックなセレクタのみ・子セレクタのみ、タイプセレクタを認めています。

.list > li
.list > dt,
.list > dd
.link > a
.image > figcaption 

このルールの適用は、デザイン、HTML+CSSコンポーネントの設計粒度、運用方法の想定にも依存するので、使う勘どころが求められます。うまく使えれば開発スピードがあがり、読みやすく、複数人チームでの実装でもコンポーネント設計に一定の統一性をもたせられると感じています。

CSSの書き方のBad例を提示する

CSSは書き方・設計次第で破綻しやすい言語です。どう書くと破綻しやすくなるか、書き方のBad例を提示しておくことでチーム内の認識すり合わせに有益です。品質担保にもつながりますし、レビュー時の指針にもなります。
以下、一例です。

.block .block__element__element {...} ## Block__element__elementの禁止

.block li {...} # 子孫セレクタでタイプセレクタを使わない

.block .anotherBlock__element {...} # 違う block の element をネストしない

.block__element {...} # block で包含しないセレクタは使わない

li {} # タイプセレクタを単体で使わない（ブラウザ間の差異を吸収する場合に限って可）

.isSelected {...} # modifier を単体で使わない

[aria-hidden] {...} # 属性セレクタを単体で使わない

.block > section,
.block > div,
.block > span {...} # 子セレクタであっても section, div, span 要素を単体で含むセレクタは使用しない

Sass のコーディングルール

プロジェクトに合わせてSassやScssを使い分けていますが、さまざまな案件での経験上、開発・運用のしやすさを考慮して生まれたルールの一例です。

• コンポーネント単位でパーシャルを分ける（1ファイル1コンポーネントとする）。
• コンポーネント間で依存はしない。
• 煩雑化を防ぐため、@extendの使用を禁止し、基本Mixinを使用する。
• element の指定時に block名を & と省略しない。

まとめ

HTML+CSSコーディングルールは、新規実装のプロジェクトに参加する時はもちろん、すでに動いているサービスで既存ルールが存在する時でもフロントエンドの技術負債を解消するための一案として提案しています。

今回紹介したルールはその一部ですが、開発の土台となるHTML+CSSのコーディングルールを社内で明示し、常におさえておくべきポイントをメンバー間で共有することで品質の担保に努めています。そのため、使いやすいルールはそのままに、フロントエンド技術や環境の変化とともに内容をアップデートしたり、新たなルールを作ることもあります。

今後も紹介していきたいと思います。

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