エンジニアが受け取って困るCSS

Web アプリを開発する際に、フロントエンドとサーバーサイドで役割分担することってありますよね。

サーバーサイドを担当するエンジニアがデザイナーさん、というかコーダーさんに書いてもらった HTML や CSS を受け取ってテンプレートエンジンに組み込む流れはよくあると思います。

そんなとき、コーダーさんがまだちょっとジュニアな感じだと、受け取ったマークアップやスタイルシートを組み込む際にエンジニア的にやりづらい、困る書き方をしていることがあります。

この記事ではエンジニアの観点から、受け取って困る CSS の記述方法をいくつかまとめてみました。

ただ困る話ばかり書いても愚痴のようになってしまうので、「こうしてほしい」という改善案も書かせてもらいました。デザイナーさんやコーダーさんの参考になればと思います。

クラス名が意味不明

.cp_ipselect .cp_sl01 { /* ... */ }

ここが困る

その部品を編集したいときや別バージョンを作りたいときに、クラス名からそのクラスが受け持つスタイル上の役割が推測できないと、どこをどういじっていいのか迷ってしまいます。

こうしてほしい

意味のわかるクラス名をつけてください。

例えば Bootstrap でいうと .btn-primary や .btn-sm は、多少省略はされていますがそれぞれ色や大きさを受け持っていることが推測しやすいです。省略せずに .button-small などであればより良いでしょう。

最低限、以下の2点に注意してほしいです。

• 省略しない
• 番号を使わない

番号に関しては、.style-01 と .style-02 という2つのクラスがあるとすると、おそらく「だいたい同じだけど一部ちょっと違う」のでしょう（ぜんぜん違う部品に連番はつけないはずですから）。

その「ちょっと違う」部分に着目して名前をつけるのがいいと思います。

大きさの違いであるなら、.style-small と .style-large のほうがわかりやすいです。色の違いであれば、.style-red や .style-blue のように色名がついていたほうがまだマシです。.style-primary、.style-secondary と抽象化されていればより柔軟な記述と言えるでしょう。

ただし、.style-top と .style-about のように違いが「画面」だというのはよろしくないです。画面が増えたときに部品を使いまわしにくいからです。画面ごとにスタイルを捉えるのではなく、画面をまたいだ汎用的な部品を組み合わせる考え方で記述しましょう。

要素名にスタイルが適用されている

.card span { /* ... */ }
.navbar p { /* ... */ }

ここが困る

部品の中に要素を追加しにくいです。

例えば上の例で言うと、.card の中にもう一つ <span> 要素が必要になったときに不要なスタイルが適用されてしまいます。.navbar の例でも同様です。

コーディングを依頼された時点で例えば <span> が一つしかなかったために要素名にスタイルを定義するのだと思います。しかしそれでは特定のマークアップでしか成立しない固定的なスタイルになってしまい、将来の変更に弱くなってしまいます。

こうしてほしい

基本的に個別の部品に対するスタイル定義の場合は、要素名にスタイルは適用せず、適用対象の要素にクラス名をつけてあげてください。

.card .card-title { /* ... */ }

特に <div> や <span> といった無意味な要素は将来追加される可能性が高いです。

テーブルの子孫要素など他の要素が追加される可能性がない場合を除き、クラスに対してスタイルを適用しましょう。

部品そのものにマージンが定義されている

.button {
  margin: 40px 80px;
  /* etc... */
}

ここが困る

別の文脈（別の場所）で部品を使いまわしにくくなってしまいます。

上の例だと、ある文脈（例えばTOP画面）でボタンを使う場合は広めの余白が必要であっても、別の文脈（例えばモーダルウィンドウの中）で使う場合は余白は不要かもしれません。

こうしてほしい

ボタンなどの汎用性の高い部品については、部品そのもののスタイルとマージンはできる限り分離してください。

マージン（部品外部の余白）は、部品そのものが持つというよりは、他の要素との関係、周囲の環境に応じて決まるべきです。

場合によって有効な実装は異なるので一概には言えません。部品ではなくその周囲の要素に余白を定義するのがよいかもしれませんし、Bootstrap では余白をユーティリティクラスとして定義しています。

部品の高さが固定されている

.form-group {
  height: 84px;
}

ここが困る

部品の内部に要素を追加したい場合に、高さが足りなくなってしまう可能性があります。

こうしてほしい

必要な場合を除き、部品の高さに固定値を指定することは避けてください。

代わりに部品の高さはパディング＋内部のコンテンツの高さで流動的に決まるように記述するのがよいでしょう。

スタイルに重複がある

.button-1 {
  background: #8be9fd;
  border: 0;
  color: #fff;
  padding: 1em 1.5em;
}

.button-2 {
  background: #f1fa8c;
  border: 0;
  color: #fff;
  padding: 1em 1.5em;
}

ここが困る

重複箇所があると編集が煩雑になります。

しかも部品の種類を増やすたびに重複が増えてしまいます。

こうしてほしい

重複しているスタイルはその部品の基本スタイルとして切り出してください。

.button {
  border: 0;
  color: #fff;
  padding: 1em 1.5em;
}

.button-primary {
  background: #8be9fd;
}

.button-secondary {
  background: #f1fa8c;
}

<button class="button button-primary">ボタン</button>
<button class="button button-secondary">ボタン</button>

すべてのスタイルを一つのクラスで表現する必要はありません。部品の基本的な体裁を表現するクラスとバリエーションを表現するクラスを分けると上手くいく場合があります。

ひとつのセレクタにJSとCSSが適用されている

#menu-toggle { /* ... */ }

var elem = document.getElementById('menu-toggle');
elem.addEventListener(click, function () { /* ... */ });

ここが困る

ある特定の id や class に対して、スタイルが適用されているのと同時に、JavaScript でもセレクタとして使用されているパターンです。

スタイルは適用したいが JavaScript での動きの定義は不要、またはその逆でスタイルは別に定義したいが動きは流用したい、という場合に対応できなくなってしまいます。

こうしてほしい

JS と CSS で使うセレクタは区別しましょう。

<div id="menu-toggle" class="menu-toggle">MENU</div>

.menu-toggle { /* ... */ }

var elem = document.getElementById('menu-toggle');
elem.addEventListener(click, function () { /* ... */ });

使い分けの方法は2つあります。

• JavaScript では id を使い、CSS ではクラスを使う。
• JavaScript で使うクラスには js-xxx と名前をつける。

どちらにせよ、使い分けができていれば OK です。

1ファイルが長い

すべてのスタイルがひとつのファイルに書かれていて2,000行とかあるパターンですね。

ここが困る

スタイルを修正したり追加したりしたいときに、ファイルを行き来して探すのが大変です。

こうしてほしい

Sass を使って部品ごとにファイルを分割してほしいです。初めから様々な機能を使いこなす必要はなく、ファイルを整理できるだけでも Sass を導入する価値はあると思います。scss 構文であれば CSS の上位互換なので入門しやすいでしょう。

まとめ

全体を通してのポイントは、拡張性です。

拡張性とは、画面の変更しやすさと言い換えることもできるでしょう。

動的な Web アプリケーションのスタイルは、柔軟で拡張しやすくなければいけません。どのような状況にも適応でき、画面の更新・変更が容易である必要があります。

これには以下の理由があります。

コンテンツ量が流動的である

動的な Web アプリの場合はコンテンツはユーザー（第三者）の投稿であることがほとんどです。ユーザーの投稿する文章が何文字であるか、タグが何個つくかなどを制御することは基本的にできません。10文字かもしれませんし、100文字かもしれません。

美しく見えるコンテンツ量に合わせてサイズを固定したスタイルを記述してしまうと、柔軟性がなくアプリとしては使えない、という結果になりかねません。

仕様は頻繁に変更される

動的な Web アプリにとって機能追加や仕様変更は当然かつ本質です。

ある部品に要素が追加されるかもしれませんし、新たに画面が追加されるかもしれません。そんなときに一からスタイルを書き直していたのでは開発スピードが遅くなってしまいます。

元の部品そのもののスタイルをなるべく変更することなく要素を追加できたほうがいいですし、既存の部品を組み合わせて新しいページを作れると便利です。

仕様の変更内容は予期できませんが、固定的なスタイルの記述を避け、最初から分かりやすく拡張しやすい記述を行うことはできるでしょう。

以上、エンジニアが受け取って困る CSS というテーマで、動的な Web アプリケーションの CSS を書く際のポイントをまとめてみました。