サイトの構築スピード＆メンテナンス性を高める！CSS設計の心得

7a8733e2aaa3cc5e966e21755bc59ea1a710a057
Grab 編集部
Web制作
サイトの構築スピード＆メンテナンス性を高める！CSS設計の心得

Webサイトを制作するうえで、レイアウトやデザインを決定するCSSは欠かせません。しかし、CSSは自由度が高く、うまく使いこなせば非常に豊かな表現が可能ですが、注意して設計しないと保守性がなくなり、サイト運営がやりづらい状態になってしまいます。

今回は、Webサイトの制作で欠かせないCSSの設計において、胸に留めておくべき心得について簡単にまとめてみたいと思います。

サイトのメンテナンス性が低い「悪いCSS」とは？

たとえば、あるサイトをイチから構築するときに、後のことを考えず思いつくままCSSを記述してしまったとします。チームで作業することや、数年にわたり運用することを考慮していないと、セレクタ(どの部分にCSSを適用するかを決めるもの)がめちゃくちゃになったり、不必要に絶対値を指定したりしてしまいます。

セレクタが整理されていないと、そのCSSが適応される範囲や内容が不明確になり、想定と異なる動きをしてしまったり、一つのデザイン調整のために何か所も編集する必要が出てきたりします。

絶対値による指定も、相対値で問題ない部分を絶対値で記述していると、表示崩れや作業量の増加につながります。

そのほかにも、いわゆる「悪いCSS」には以下のようなものがあります。

命名規則が独自ルールになっている…

セレクタに名前を付けるとき、名前から内容が推測できないものだと、別の担当者が修正する際にどこを修正すべきかわからなくなってしまいます。また、セレクタの名前が紛らわしいと、新しく追加したセレクタとバッティングしてしまう可能性があります。

HTMLの構造に依存している…

セレクタを指定する際、HTMLの構造に依存してしまうことがあります。この状態では、HTMLを修正する際にCSSも修正する必要が生じる可能性が高まります。

このようなCSSが記述されたサイトを更新しようとすると、ちょっとしたリニューアルをしたり、新たなコンテンツや機能を加えたり、極端なことをいえばボタンをひとつ増やすだけで四苦八苦してしまう、そのようなケースが起こってしまいます。

「前任者が手がけたCSSを前にして途方にくれてしまった」

そんな経験のあるデザイナー、マークアップエンジニアも多いでしょう。

構造が複雑すぎるために、ヘタなところを触ってデザインの整合性を保つことができなくなったり、想定外の場所にまでCSSが適応されてしまったりする場合があります。「ボタンをひとつ追加する」という簡単に思える作業に何時間も費やしてしまうことも考えられます。

こうしたコーディング・マークアップを「保守性がない」「再利用性が低い」といったりします。そのようなことにならないようにするためには、何を心がけるべきなのでしょうか。

良いCSSは「保守性が高い」

それでは、良いCSSとは何なのでしょうか。
Webデザインの権威であるPhilip Waltonは、良いCSSを以下のように定義しています。

予測しやすい

予測しやすいCSSとはルールが期待通りに振る舞うことを意味する。ルールを追加・更新したとき、そのルールが意図せずサイトの一部に影響を与えるべきではない。滅多に変更されない小規模なサイトであれば、このことはあまり重要ではないが、数十、数百ページの大規模なサイトであれば、予測しやすいCSSは必須といえる。

再利用しやすい

CSSのルールは抽象的で、十分に分離されているべきである。それはパターンとすでに解決した問題を書きなおす必要なく、既存のパーツから新しいコンポーネントを速くつくることができるということだ。

保守しやすい

サイトに新しいコンポーネントと機能が追加・更新されるか、再編される必要があるとき、既存のCSSのリファクタリングを必要とすべきではない。ページにコンポーネントXを追加するときに、そのわずかな存在によってコンポーネントYを壊すべきではない。

拡張しやすい

サイトが大きく、複雑に成長していくにつれて、通常はたくさんのデベロッパがメンテナンスのために必要となる。 拡張しやすいCSSとはひとりのデベロッパか、大きなエンジニアチームかを問わず、容易に管理できることを意味する。またそのサイトのCSSアーキテクチャに、巨大な学習曲線を必要することなく容易に近づけるという意味でもある。あなたが今日CSSを触る唯一のデベロッパだからといって、先々にも常にあなただけであるというわけではない。

引用：https://philipwalton.com/articles/css-architecture/

一言でまとめてしまうと、長期的なサイト運営の中で発生する編集作業が行いやすいということです。サイトを運営する中で、デザインを調整したり、別の要素を追加したりすることは頻繁に起こります。また、担当者が変わることもあります。

「悪いCSS」は、編集に余計な手間がかかったり、別の担当者が行った際にミスが発生したりする確立が高くなります。一方で、「良いCSS」は、どこを編集すればいいかが明確で、誰が見てもすぐに理解できるように設計されています。

CSS設計は“オブジェクト指向”で！

CSSは非常に自由度が高く、一つのデザインを作成するために様々な記述方法が存在します。そこで、サイトを構築する、あるいは更新する際には、フレームワークやルールをチームで共有しておく必要があります。

CSSのフレームワークやルールにはSMACSS、BEM、MCSSなど様々なものがありますが、今回は日本でも普及しているOOCSSを紹介します。

「Object-Oriented CSS」略して「OOCSS」は、文字通り“オブジェクト指向”という考え方のもとで誕生したCSS設計の手法です。

言葉で説明しようとするとなかなか難しいですが、簡単にいえば「無駄をなくし、メンテナンス性を上げるために“クラス分け”をすること」であるといえます。

たとえば、あるサイト内に同型、同サイズ、ただし色違いのボタンを複数つくるとき、ひとつひとつ記述していたのではCSS全体に同じ数値が何度も登場して複雑化してしまい、いざボタンを増やしたり減らしたりするときに苦労してしまうことが考えられます。

上記の例では「幅(width)は100pxで高さ(height)は50pxの赤いボタン」と幅(width)は100pxで高さ(height)は50pxの青いボタン」をCSSで記述しています。この記述方法では、ボタンの数だけ「100px」「50px」が無駄にCSS上に散乱してしまうことになります。

こうした記述は冗長構成と呼ばれ、保守性が低くなる原因の一つです。もし、ボタンサイズを「100px」「70px」に変更したい場合、すべてのボタンのCSSを編集する必要があります。

.button-red {
width: 100px;
height: 50px;
background-color: #ff0000;
text-align: center;
}

.button-blue {
width: 100px;
height: 50px;
background-color: #0000ff;
text-align: center;
}

一方、ここでオブジェクト指向の考え方を活用したOOCSSを使用すれば、そのようなことにはなりません。

OOCSSでは、「ボタンのサイズ」や「文字の大きさ」といった“構造”と、「ボタンの色」という“見た目”を分けて記述します。

.button {
width: 100px;
height: 50px;
text-align: center;
}

.blue {
background-color: #ff0000;
}

.red {
background-color: #0000ff;
}

この例では、「ボタンの幅は100pxで高さは50px」「赤いボタン」「青いボタン」を分けて記述しました。

これなら、以下「何色のボタンを設置したいのか」だけを記述していけばいいのでCSSは全体的に見やすく、シンプルにまとまります。もしもボタンのサイズを変更したいならば「button」の中を変えるだけで、関連するすべてのボタンのサイズを変更することができます。

また、CSSの記述がわかりやすくなるだけでなく、HTML側の記述もわかりやすくなるメリットがあります。

OOCSSの書き方は、レゴブロックを組み立てるようなイメージといわれています。構造や見た目のスタイルをあらかじめ用意しておき、HTML要素のclassを組み合わせて利用します。

そのため、命名規則を明確にしておけば、HTMLを見るだけでどのようなデザインが適応されるかイメージが付きます。オブジェクト指向で最初にしっかりとCSSを設計しておけば、HTMLによるマークアップが非常に楽になります。

さらに、組み合わせによりHTML側でデザインのコントロールができるため、汎用性のあるCSSを設計しておけば、他のサイトでも使いまわすことができます。

OOCSSのデメリット

オブジェクト指向でCSSを設計すれば、コード量を減らすことができ、編集も容易になります。その反面、どこにどのスタイルが適応されるのが分かりにくくなったり、HTMLのclass指定が非常に複雑になったりしてしまう可能性があります。

そうなってしまう一番の原因は初期設計にあります。今から作成するサイトにはどのようなCSSが必要なのかをあらかじめ把握し、それをどのように分類すれば効果的なオブジェクト指向になるのかを考える必要があります。

例えば、「button」でサイズを指定し、他のクラスで色や細かな見た目を調整するとします。しかし、サイト内で使うボタンサイズが多い場合は結局サイズを指定しなおす必要がありますし、ほとんどのボタンで角丸(border-radius)を使うのであれば、「button」の中に記述したほうが効率的です。

このように“なに”と“なに”を組み合わせて求めるデザインを作るのが効果的かは、あらかじめきちんと設計しておきましょう。

また、構造と見た目を切り分けることが原則ですが、そもそもどこまでが“構造”でどこからが“見た目”なのかは個人の感覚に依存してしまいます。これについては、色に関するスタイル(color, background-color, border-color, border-radiusなど)は見た目で、大きさや形(width, height)は構造とする、などのルールを決め、共有しておく必要があるでしょう。

まとめ

CSS3.0が普及してから、CSSでできることは飛躍的に増えました。これまで一つ一つ画像を作成していた部分が、CSSで再現できるようになり、サイトの表現力や表示速度、異なるデバイス幅に対する最適化などが改善されました。

一方で、できることが増えすぎたため学習コストが高くなったり、個人のスキル・感覚に依存する部分が増えたりすることも事実です。

今回はOOCSS(オブジェクト指向CSS)という考え方を紹介しましたが、目的とするデザインはもちろん、チームの規模や性格によって、適切な考え方は異なります。

Grabでは、今後様々なCSSの書き方や考え方を紹介していくので、ぜひあなたのチームに合った考え方を見つけてください。