CSSの教科書を読んで自分なりにまとめてみたこと（第5章） #CSS

はじめに

谷拓樹さんのWEB制作者のためのCSS設計の教科書を読み、自分なりにまとめたものです。
自分のメモとして残しておきたいので、詳細を多少端折っていますので、気になる方は購入してみてください。
数回に分けて投稿する予定です。

コンポーネントを個別に管理する

コンポーネントとして設計されたルールは、コンポーネント単位でコードを管理できるようになっている。作られたコンポーネントをCSSファイルとしてどう管理するかを考える。

test.css

# Base

.body {
……...
}

# Layout

#header{
……….
}

#footer{
……….
}

例えば、SMACSSやMCSSのようなカテゴリ、レイヤールールにのっとって、次のように1つのCSSファイルの中で整理できる。
それほどスタイルが多くない、または関わる開発者も少ないプロジェクトであればこうした1つのCSSファイルの中で、セクションを分けて管理するのはさほど問題がない。

しかし、もっと多くのコンポーネントで構成されていたり、また多くの開発者が手をいれる可能性があるのであれば、ファイルを分割するほうが好ましい。
分割されていれば、カテゴリやレイヤーごとに開発を分担し、編集箇所が衝突するようなことも少なくなる。

ただし、開発・管理の都合だけでファイルを細分化すると別の注意点も出てくる。リソースのリクエスト数（通信数）がページの表示速度に影響するので、単純にCSSファイルを分割し、や@importを使ってファイルをバラバラと読み込もうとするとそれが、速度低下につながる。

つまり、理想としては開発上は管理面の利点で分割したいのだが、プロジェクトの公開状態のときにはリクエスト数を抑えるため1つのファイルにしておきたいということ。

Sassを使った管理法

Sassとは　http://sass-lang.com/guide

解説でも出てくるので、特に重要なのは、@import @extend Placeholderの3つである。

master.scss

@import “button”;
@import “media”;

button.scss

 .btn {
   ………...
 }

media.scss

.media {
  …….
}

master.css

#コンパイル後
 .btn {
   ………...
 }

.media {
  …….
}

マルチクラスとシングルクラス

1つ1つのコンポーネントをCSSのクラスとし、それを複数組み合わせることでUIを作る方法
→「マルチクラス」

test.html

<button class=“btn btn-large”ボタン</ button>

コンポーネントさえ用意されていれば、HTMLのマークアップ上で大体のUIが作れること
CSSはマルチクラスのほうがシンプル

単一のクラスによるアプローチ
→「シングルクラス」

test.html

<button class=“btn”ボタン</ button>

クラスが短調になりにくい
マークアップ（HTML）はシンプル

とはいえ、シングルクラスを手動で実現しようとするのは、骨が折れる。そこで、Sassの@extendを使えば、CSSをの中でもOOCSSを意識して組合わせシングルクラスで実現可能。

test.sass

.box {
        margin: 0 0 30px;
        padding: 15px;
        border: 1px solid #ccc;
}

test.sass

// .box で使ったスタイルを継承
.item {
        @extend .box;

}

.box, .item {
  margin: 0 0 30px;
  padding: 15px;
  border: 1px solid #ccc;
}

.boxの情報がインポートされる。
このようにすればマークアップ上はすっきりするが、マルチクラスの設計と比べて必要なクラスの数が多くなる。

参考↓
http://nicolasgallagher.com/about-html-semantics-front-end-architecture/

セマンティックなクラス名

test.sass

%box {
        margin: 0 0 30px;
        padding: 15px;
        border: 1px solid #ccc;
}

main.sass

// .box で使ったスタイルを継承
.item {
        @extend %box;
}

.item {
  margin: 0 0 30px;
  padding: 15px;
  border: 1px solid #ccc;

}

Placeholder Selectorを使うことで、(.の代わりに％を用いる）単品では使わないセレクタの出力を抑える。

Sassを使ったシングルクラスと、@extendのアプローチは、マークアップ上のクラス名を任意のものにできる。
もっと意味のある（セマンティックな）名前にしたいと考える人もいるであろう。それは上のような.btnや.boxのような名前ではなく、情報の保存ボタンであれば、.saveというクラス名をつけるといったことである。

こうしたセマンティックな、コンテンツ派生の意味をお持つクラス名というのは、HTML5のclass属性の使用における次の定義を持っている。（筆者はクラス属性のコンテンツに求める見た目を説明する値ではなく、コンテンツ自体の特性を説明する値を利用すること）

参考↓
https://www.w3.org/TR/2014/CR-html5-20140429/dom.html#classes

CSS上でそのクラス名を見れば、どのコンテンツに使われているルールであるかが明白と言うのは一つの利点であるといえる。
しかし、コンテンツ派生の命名である場合、再利用性は大きく損なわれる。
.saveを「次のページに進む」ボタンのUIに適応すると、名前と要素の意味が不一致になる。
逆に.btnのような抽象的な名前であれば、次のページに進む」ボタンのUIに適応しても何らおかしくはない。

btnのような抽象的な命名は、class属性の仕様のようなコンテンツ派生命名ではないものの、開発者がその振る舞いを理解できる名前で合致していれば十分セマンティックといえるでしょう。
マルチクラス、シングルクラスどちらを使うかということと同じで、どちらのアプローチにも正解はないが、中長期的な運用のなかで、メンテナンス性を高く維持できるかについては、開発者の中であるいはサービスの作り方に応じて統一すればよいものである。