ZeroPlus Media > Web制作 > HTML/CSS > CSSにルールを設けてさらに保守性を高めよう part1

CSSにルールを設けてさらに保守性を高めよう part1

HTML/CSS

2022/07/23

2023/06/02

この記事では、CSS設計の基礎について学習していきます。

CSS設計は、読みやすく保守しやすいCSSコードを書いていくために必要不可欠なものです。CSS設計には、「CSSの詳細度」が大きく関わってきます。

CSSは上書きされる優先順位があるタグ, class, idなどセレクタの書き方ごとに点数があり、点数が高い方が優先される同じポイントの場合は下に書いた方（後に読み込まれた方）が優先される

CSSの詳細度についての理解を深めたい方は、こちらも併せてお読みください。

CSSの詳細度を学ぼう

適当に書いたCSSの問題
- 共同開発や引き継ぎが大変
CSS設計とは
ZeroPlusでの命名規則
クラスの命名で使えるフレーズ集

適当に書いたCSSの問題

何も考えずに適当にCSSを書いてしまうと、次のような問題が発生してしまいます。

共同開発や引き継ぎが大変

会社のホームページやメディアサイトなど、開発規模の大きいものや作った後の運用が必要なものについて考えていきます。

共同開発における問題

開発規模が大きいサイトは、複数人で分担して作業を進めることが多いです。

共同で開発を行う際、各々がルールなしでclassの命名やスタイルの記述を行うと、異なる箇所でセレクタが被ってしまい、予期しないスタイルが当てられるといった事態が発生することがあります。

既存Webサイトの修正や改修における問題

機能やページの追加、リニューアルなどによって、後からWebサイトのコードを修正する場合があります。

その際、過去に自分で書いたコードや他人が書いたコードを確認する必要があります。ルールがなく読みにくいコードだと、確認が大変なばかりでなく、修正したコードが複雑化してしまって思わぬ挙動になってしまう可能性があります。場合によっては、ゼロからコードを書き直す必要も出てくるかもしれません。

こちらは問題の一例です。CSS設計を学んで、それに準じたコードを書けるようになると、さまざまな問題が解消されます。

CSS設計とは

CSS設計を一言であわらすと「”良いCSS”を書くための考え方に基づいたルール」です。

一般的に「良いCSS」とされるものは次の４つの考え方をもとにしています。

予測しやすい

再利用しやすい

保守しやすい

拡張しやすい

これは、Googleのエンジニアである、Phil Walton氏のブログで提唱されたものです。

それぞれ詳しくみていきます。

予測しやすい

ブログの該当箇所を和訳すると、次のように書かれています。

予測可能なCSSは、ルールが期待どおりに動作することを意味します。ルールを追加または更新するときに、意図しないサイトの部分に影響を与えるべきではありません。めったに変更されない小さなサイトでは、これはそれほど重要ではありませんが、数十または数百ページの大きなサイトでは、予測可能なCSSが必須です。

つまり、「他の人がコードを見たときに、記述がどのように影響しているかわかりやすいように書こう」ということです。

例えば、class名の付け方にルールがあったり、スタイルの優先度が整理されていたりすると、コードを編集する際にどのように影響されるかがわかりやすいです。

逆にそれらができていないと、部分的な変更で別の部分が変わったりして、必要以上に修正作業に時間がかかってしまいます。

予測しやすいCSSを書けると、次のようなメリットがあります。

修正するときに、CSSの変更で予想外のことが起こりにくい
修正するときに、どこにどのスタイルが当たっているかの予測がつけられる（探す手間が省ける）
自分で書いているときに、スタイルをどう当てるかを迷わずに書くことができる

他の人や、後から自分が読んでわかりやすいCSSを書くように意識しましょう。

再利用しやすい

再利用については、次のように書かれています。

CSSルールは抽象的であり、十分に分離されている必要があります。これにより、すでに解決したパターンや問題を再コーディングしなくても、既存のパーツから新しいコンポーネントをすばやく構築できます。

つまり、「使いまわせるパーツのスタイルはまとめよう」ということです。

コンポーネントというのは、使いまわせるパーツのことです。大きい括りで見れば、複数ページで同じ形を使い回すヘッダーやフッターもコンポーネントの一つであると言えます。

サイト全体で、同じ色やフォントサイズ、ボタンやアイコン、見出しのデザインを使用することはよくあります。その際に、都度同じ記述をしていたら時間と手間がかかりますし、変更があった時に一つ一つ修正するのも大変です。

再利用しやすいCSSを書けると、次のようなメリットがあります。

記述量が大幅に減らせる
修正する時に、一括で変更ができる

Web制作で、同じ形状のパーツのデザインを使うときは、スタイルをまとめるようにしましょう。

保守しやすい

保守については、次のように書かれています。

サイトで新しいコンポーネントや機能を追加、更新、または再配置する必要がある場合、既存のCSSをリファクタリングする必要はありません。コンポーネントXをページに追加しても、コンポーネントYが存在するだけで壊れてはなりません。

つまり、「修正・変更した時にわかりやすい書き方にしよう」ということです。

保守のしずらいCSSでは、

予測していないスタイルの上書きが起こったり、
重なり順を書くのに他の要素のz-indexを考えないといけなかったり、
一つ書き換えたら全く別のものが崩れてしまっていたり、

と、修正や変更（メンテナンス）がとてもしづらく、さまざまな問題が発生します。

修正や変更がしやすいことは、継続した運用を行うWebサイトにおいて、非常に重要なことです。

拡張しやすい

拡張性については、次のように書かれています。

サイトのサイズと複雑さが増すにつれて、通常、より多くの開発者が維持する必要があります。拡張可能なCSSは、1人または大規模なエンジニアリングチームが簡単に管理できることを意味します。また、膨大な学習曲線を必要とせずに、サイトのCSSアーキテクチャに簡単にアクセスできることも意味します。今日CSSに触れている開発者があなただけだからといって、それが常に当てはまるとは限りません。

つまり、「追加変更があったときに、最低限のコストで作れるようにしよう」ということです。

例えば、既存のボタンと背景と文字色だけ違うボタンを作ることになったとします。そのとき、ボタンの共通部分と相違部分で違うclassにスタイルを当てていれば、classを一つ追加するだけでボタンのスタイルが完成します。

拡張のしやすいCSSを書けると、次のようなメリットがあります。

追加変更がきたときに、手間と時間をかけずにコードが書ける
変更があったとしても、容易に変更ができる

保守のしやすさと通じるところがありますが、いずれにしても、変更や追加の際に最低限の手間と時間でコードをかけるように、初めからルールを作ろうということです。

ここまで、CSS設計の重要性と考え方を伝えてきました。

すごくざっくりまとめると「後から書き換えたり、他人が見る想定でCSSを書いていこう」ということです。

Web制作に限らず、プログラミングでの開発は複数人で作業を行うケースが多いです。そのため、それらの修正でストレスを減らす書き方ができるエンジニアはとても喜ばれます。

ZeroPlusでの命名規則

ZeroPlusの教材では、先述した保守しやすいコードを書くため、原則classを使ってスタイルを当てています。

以下が、ZeroPlusの教材のCSS設計の一部です。

新しい言葉に関する解説は下にまとめて記述します。

原則として、英語で書くこと。

ただし「特定商取引法」など、翻訳が困難または冗長になるときは、「.tokusyoho」のように書くなど例外は認める。（このような場合、慣例を参照する）

基本的な命名規則はBEM（※下に解説あり）

ex.).block_element__modifer

2単語以上をつなげる場合はハイフン（-）

ex.) .class-name

モジュール・レイアウト・ユーティリティクラスに関しては接頭辞をつける

ex.).m_class-name

ページ独自のスタイルはページの名前を接頭辞とすることとする。（※下に解説あり）

ex.).top_block_element__modifier

汎用的に使用可能な名前

wrapper
inner
header
body
footer

これらは後述する5つのグループいずれにおいても、必要に応じて汎用的に使用することができます。

-wrapperはモジュールのルート要素の親クラスとして使用することを想定しており、子要素ではありませんが「そのモジュールに属する」として、子要素と同じようにアンダースコアで結合します。

単語を省略する場合

category(ies) → cat(s)
column → col
level → lv
description → desc
button → btn
image → img
thumbnail → thumb
number → num
text → txt
small → sm
medium → md
large → lg
key visual → kv
call to action → cta

新しい単語：BEM

BEMはclass命名のルールの一つで、Block（ブロック）, Element（エレメント）, Modifier（モディファイア）の頭文字をとってBEMという名前になっています。

一つの塊をBlockとします。そのBlockに含まれる要素をElementとして、BlockやElementの装飾や動作のパターンをModifierとしてclass名をつけます。

教材では次のように書いています。

<div class="pagination">
  <span class="pagination_numbers pagination_numbers__current">1</span>
  <a href="" class="pagination_numbers">2</a>
  <span class="pagination_between">…</span>
  <a href="" class="pagination_numbers">10</a>
  <a href="" class="pagination_numbers pagination_numbers__next"></a>
</div>

paginationがBlockで、_numbersや_betweenがElementです。

__currentや__nextはModifierで、pagination_numbersの別パターンとして作られています。

この書き方をすると、予測しやすく、保守しやすいコードがかけます。

※BEMのBlock, Element, Modifierの繋ぎ方はさまざまな書き方があるので、現場や参考サイトによって異なる場合があります。

新しい単語：接頭辞

BEMで書いたclass名の前につける文字のことです。

そのclass名がなんの役割を果たしているかを示したり、class名の重複を避ける目的でつけられます。

教材では次の接頭辞と役割が対応しています。

接頭辞	役割
l_class-name	汎用的に使えるレイアウトに使う。sectionレイアウトなど。 headerやfooterは便宜上一つのレイアウトとして扱う。
m_class-name	汎用的に使えるモジュール（コンポーネントと似たモノ）に使う。
u_class-name	ユーティリティクラス（単一のスタイル・役割を持つclass）に使う。
js_class-name	jsセレクタに使う。

接頭辞を書くことで、予測・保守・拡張のしやすさ、書き方によっては再利用のしやすさにもつながります。

今回の記事では、「こういう書き方があるんだ」くらいの理解で大丈夫です。

興味のある方は「PRECSS」や「FLOCSS」などで調べると、より理解を深められると思います。