OthloBlog - オスロブログ -

名古屋のIT系学生コミュニティOthloTechのブログです。

もう破綻しない!web制作におけるCSS設計の考え方

f:id:yuverna:20180619003837p:plain お久しぶりです、ちーずです。
最近、ちょくちょくあだ名の由来を聞かれるのですが、実は食べ物のちーずではなくてアンパンマンのちーずがあだ名の由来です。

今回は、チームでweb制作をする時に考えて欲しいCSS設計に関しての記事を書こうと思います!

記事の内容

  • 対象読者はCSSにちょっとでも関わることのあるweb制作者です。
  • 主にCSS破綻あるあるとその原因、解決方法を書いていきます。
  • よく使われているCSS設計とスタイルガイドに関しても軽く挙げていきます。

そのCSS、破綻していませんか?

みなさん、CSSを記述していくうちにこんなことが起きていたりしませんか?

  • 長すぎてどこに何が書いてあるか考えたくもない。
  • さっきも同じようなスタイルあてたような。どれだっけ。
  • このスタイル...どこで使ったんだっけ?
  • スタイルが当たらない。とりあえず!importantつけちゃえ!
  • クラス名... 自分がわかればなんでもいっか!
  • あれ!いつのまにかスタイルが崩れてる!

CSSを書いたことがある人だったら誰しもがこのような経験をしたことがあると思います。 このようなCSSは破綻したCSSと言われています。
CSSを書くことは非常に簡単であり、コードを自由に書いてもその場しのぎでスタイルを当てることができます。
しかし、その簡単さや自由さ故に、破綻しやすいというリスクを抱えています。

なぜCSSが破綻してしまうの?

破綻する原因の例として、以下のようなことが挙げられます。

  • CSSを書く上での明確なルールがない。
  • クラス名をみても何をしているかがわからない。
  • 説明書のようなものがない。
  • HTML構造や書く順序など、何かしらに依存している。

良いCSSを書くには、

  • 拡張性(機能や要素の拡張がしやすいか)
  • 保守性(ソースコードの追加、修正が簡単にできること)
  • 明瞭性(期待通りに振る舞うか)

の三点が大切であると言われており、上の例はこれらが欠如したが故に破綻しています。

それではどのようにCSSを運用して行くのが良いのでしょうか?

解決方法1 : CSSを設計しよう!

CSSもプログラミングと同じく、書き始める前に設計をしなければなりません。
特に、先ほど挙げました拡張性、保守性、明瞭性を意識してCSSを設計していく必要があります。

しかし、破綻しないCSSの設計を自分でするのは正直大変ですし、ミスも起きやすいです。
なので、世の中に出回っている上記の三点を満たす設計手法を参考にすると良いでしょう。
特に有名な設計手法として、OOCSS、BEM、SMACSS、FLOCSSなどがあります。

OOCSS

OOCSSはObject Oriented CSS(オブジェクト指向CSS)の略であり、Yahoo!のNicole Sulivan氏によって開発された設計手法です。
構造と見た目の分離をさせて、それらを組み合わせてスタイルを書いていきます。

Nicole Sulivan氏のGitHubのwikiに詳しく書いてありますので、ぜひこちらを参考にしてみてください。 github.com

BEM

BEMはYandexという会社が作った設計手法であり、Block、Element、Modifierの頭文字から命名されました。
名前の通り、

  • Block(独立して動作する構成要素)
  • Element(Blockの中の子要素)
  • Modifier(BlockやElementの装飾)

の三つで設計が成り立っています。
命名規則がしっかりしており、block__element--modifierと変わった書き方をしますので、見慣れるまで少し時間がかかるかもしれません。

BEMの公式ドキュメントでは図を用いて詳しく説明されているので、参考にしてみてください。

SMACSS

SMACSSとは、Scalable and Modular Architecture for CSSの略であり、Jonathan Snook氏が提案した設計手法です。
SMACSSでは、下記の分類でスタイルを考える設計となっています。

  • Base (デフォルトのスタイル)
  • Layout (Moduleの配置を決めるレイアウト、l-〇〇, layout-〇〇と命名する。)
  • Module (再利用可能なパーツ)
  • State (Layout、Module 状態、is-〇〇と命名する。)
  • Theme (Layout、Moduleの外観)

命名規則が緩和されており、設計自体のルールもわかりやすいため、設計手法の入門として初心者も使いやすいと思います。 SMACSSの公式ドキュメントでは日本語訳されたPDFがありますので、こちらを参考してみてください。

FLOCSS

FLOCSSは上記で紹介しましたOOCSS、SMACSS、BEMのいいとこ取りをして作られた設計手法です。
命名規則はBEM(block__element--modifier)で、ルールはFoundation、Layout、ObjectとSMACSSっぽく分類されており、そのObjectの中でComponent、Project、Utilityに分類されています。
FLOCSSは一度BEMやOOCSS、SMACSSを経験してから導入するとより使いこなせると思います。

参考ドキュメントはhilokiさんのGitHubから引用させていただきました。 github.com

ざっと説明しましたが、どれを導入すれば良いか迷うと思います。
下記記事では、それらの設計手法のメリット・デメリットなどが詳しく書かれていますので、こちらを参考にしてみてください。
qiita.com

解決方法2 : スタイルガイドを作ろう!

f:id:yuverna:20180618051138p:plain さぁ、設計ができたぞ!よし、他の人にスタイルを当ててもらおう!って思っても、コードのみを渡すだけではなかなか伝わらなかったりします。 そのような時は、スタイルガイドを導入すると良いでしょう。

スタイルガイドとは、CSSを当てる際のルール表のようなものです。
上の画像のように、実際に書くhtmlの例やスタイルの当て方などを書くことによって、設計者以外でもルールを理解し、スタイルを当てることができます。

また、スタイルガイドを自動的に生成するジェネレーターも多く出回っていますので、自分に合うジェネレーターを取り入れると良いと思います。

下記記事の比較表がわかりやすかったので、参考にしてください。 qiita.com

解決方法3 : コードにもしっかりコメントを書こう!

設計に基づいてコードを書いていったけど、どうしてもスタイルの上書きがしたい、!importantを使いたい...なんて日がきてしまうかもしれません。
また、設計に基づいてはいるもののコードの量が膨大になってしまい、どこに何が書いてあるのかわからなくなってしまった...ってことも起きてしまうかもしれません。

そんな時に大切になるのが実はコード上のコメントです。
コードを書くのも読むのも人であるため、コード上でのコミュニケーションって結構大切です。

もし!importantを使いたい場合は

/* 〇〇を上書きするためのスタイル */
.hoge {
  color: #333 !important; /* 色の上書き */
  border: 1px solid #333 !important; /* borderの上書き */
} 

などとコメントを残すと、他の人になぜ!importantが使いたかったのかを伝えることができます。

また、コードが長くなりすぎた場合、

/*----------------------------
    ここから〇〇
----------------------------*/

などと目印となるコメントを書くと、より気付きやすく他の人が見てもわかりやすいコードになるでしょう。

解決方法4 : Lintを導入しよう!

解決方法3まででほとんどバッチリですが、単位の書き方やスペースの取り方など、人によって書き方が違うことが結構あります。
そのような小さなことで、コードの一貫性が失われてしまわないようにLintにソースコードをチェックしてもらいましょう。

Lintとは、コンパイラより詳細かつ厳密なチェックを行うプログラムであり、CSSでは;忘れやインデント、単位のチェックなどを行ってくれます。

Lintの書き方、内容に関してはこちらの記事が参考になります。 qiita.com

快適なCSSライフを!

いかがだったでしょうか? 一度でも、自分のCSSを振り返ってみて、設計を導入してみたりスタイルガイドを生成してくれたら、嬉しいです。 それでは快適なCSSライフを!!