ZeroPlus Media > L_HTML/CSS > Step4 > CSSにルールを設けてさらに保守性を高めよう part1

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

2022/07/14

2022/10/04

はじめに
CSSの問題
- 共同開発や引き継ぎが大変
CSS設計とは
ZeroPlusでの命名規則
- BEM
- 接頭辞
クラスの命名で使えるフレーズ集
まとめ

はじめに

そろそろHTML, CSSにも慣れ始めた頃だと思います。今のみなさんは、すでにWebサイトのマークアップが一通りできる状態です。

しかし、見た目ができればよい、というスタンスだけでコードを書いていると、実際に仕事をしたりしたときに少し大変になってくるかもしれません。

それを回避するためには「CSS設計」というものを学び、導入する必要があります。

これから本記事を通して、CSS設計の考え方を学んでいきましょう。

この記事で身につく内容

よいCSSとは
ZeroPlusで使用している命名規則
クラス名に使える名前

また、「CSSの詳細度」がCSS設計の内容に大きく絡んできますので、理解を深めたい方は読んでみてください。

CSSの詳細度を学ぼう

上の記事の内容を簡単にまとめると

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

CSSの問題

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を考えないといけなかったり、一つ書き換えたら全く別のものが崩れてしまっていたりと、カオスな状態になってしまいます。

保守のしやすさを「保守性」「メンテナンス性」などと言いますが、これらはCSS設計が果たす役割の中で最も重要だと捉える人も多いです。

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

修正・変更がとてもしやすい

これだけ？と思う方もいるかもしれませんが、運用をする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

これらは必要に応じて汎用的に使用することができます。

単語を省略する場合

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

いろいろありますが、ざっくりそういうルールでZeroPlusでは管理されている、ということを把握してもらえればここではOKです。

ここで出てきた「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」などで調べると、より理解を深められると思います。