TSUNAGU GROUP TECHNOLOGIES

TGT TechBlogTGT TechBlog

フロントエンドからバックエンドまでの技術ナレッジ

Sassの色管理方法について考えてみた

sass-colormangaement


管理サイトのプチリニューアルをやっているのですが、Sassを使った色管理について、試行錯誤した過程や結果を、事例を交えて共有します。
まず、色を変数化して管理する目的は2点あると思います。
1. サイトで使う色を統一し、むやみに色を増やさない
⇒デザインの統一性の担保
2. 同じ機能を持ったモジュールの色を統一して管理する
⇒新規・保守制作時の効率化

1.サイトで使う色を統一し、むやみに色を増やさない

過去の案件では、様々な過ちを犯してきました。
視認できないほど僅かな差しかない色を使い分けて作ってしまったデザインを、そのまま忠実にコーディングしてしまったり、
保守業務で、新しいモジュールを追加する際、同じような機能を持つモジュールがあることに気づかず、別の色を勝手に作ってしまったり。
そうすると、サイト全体のデザインの統一性がとれなくなります。
はた目からは分からないとしても、やはり少し気持ち悪さが残ります。
そこで、まず、サイト内で使う色を洗い出して、以下のように変数化しました。

// ベースカラー
$base-color-600: #484b54;
$base-color-500: #585c67;
$base-color-400: #8b8d91;
$base-color-300: #d6dae2;
$base-color-200: #f0f3f6;
$base-color-100: #f5f6fa;
// メインカラー
$main-color: #ffa500;
$main-bg-color: #fcf8ed;
// サブカラー
$sub-color: #4a98f1;
// アクセントカラー
$accent-color-success: #4cdb8f;
$accent-bg-color-success: #dbf7e8;
$accent-color-danger: #f9446a;
$accent-bg-color-danger: #fae4e9;
$accent-color-attention: #fcd419;
$accent-bg-color-attention: #ffffe8;
// カテゴリーカラー
$category-rtype-color: #c74700;
// 無彩色(黒と白はblack,whiteで記述すること)
$non-colored-color-gray-600: #333;
$non-colored-color-gray-500: #797979;
$non-colored-color-gray-400: #a3a3a3;
$non-colored-color-gray-300: #d1d1d1;
$non-colored-color-gray-200: #eee;
$non-colored-color-gray-100: #f9f9f9;
ベースカラー:サイトの基調となっている色。サイトの大部分を占める色。背景色やボーダー色に使う。色の濃淡により数字で命名。
メインカラー:サイトの核となる色。ロゴの色など。デザインによっては、ベースカラーと同じ場合もあるかもしれない。
サブカラー:メインカラーに準ずる、サイト内で使う色。ボタン色などで使う。
アクセントカラー:メイン・サブ以外で、サイト内で使う色。メイン・サブ以外のボタン色や、アラートの色もここに定義している。
カテゴリーカラー:カテゴリー毎に中心となる色が異なる場合、ここに定義。今回の案件には、メイン・サブの2種類のプランが存在し、サブプランで使う色をここに定義した。これは定義する必要がない場合も多そう。
無彩色:グレーのパターンを濃淡ごとに定義。黒・白はカラーネームを利用する。
検索で色々と調べると、「$base-color-200」のような番号での命名ではなく、「$pale-sky-blue」(淡い空のような青)のように、色1つ1つに固有の名前を付けるやり方もあるようです。
確かに、番号より名前の方が、直感的に色を思い浮かべやすい気はしますが、今回は、色の濃淡のバリエーションも多めに作りたかったので、採用しませんでした。
色数が少ないサイトの場合は、固有名も良いかもしれません。
なので、制作中、「あの色使いたい」と思った時は、デザインを作ったsketchに戻って色番号を確認してから、その色番号を定義した変数を使いました。
Sketch側でも、階層を使って、カラーカテゴリー分類しておくと見やすいです。
だんだん慣れてくると、sketchを見なくても変数名を覚えていたり、エディタで履歴が出てきたりするので、そこまで煩わしいことはありませんでした。
以上のように、サイト内で使う色を網羅して変数に定義しました。
もし、保守の際に新しく使いたい色が増えた場合は、ここに定義を増やしてから使うつもりです。

2. 同じ機能を持ったモジュールの色を統一して管理する

サイト内で使う色が定義できたら、それを使いながら、機能ごとに色を定義します。
フォント色、リンク色、ボーダー色、背景色などです。

// ベースフォントカラー
$font-color: $non-colored-color-gray-600;
// リンクカラー
$link-color: $main-color;
$actlink-color: $sub-color;
上記が、現在の定義ですが、これでは不十分だと思っています。
FLOCSSを採用するので、機能ごとの定義はそちらで管理すればいいと思っていた節があるのですが、ボーダー色、背景色くらいは、機能別での定義もしておいた方が便利かと思いました。
コーディングする時に、各モジュールの枠毎に「$base-color-200」という変数名をひっぱり出してくるよりは、「$border-color」の方が思い出しやすいですし、
枠の色を変えようと思った時も、後者は一箇所の変更だけで済みます。
ただし、定義する範囲は、今後の保守のことを考え、同じ変更を加える(であろう)範囲になるよう、注意が必要です。
まとめると、制作する上で、効率化した方が良い、かつ、一括の変更を加える範囲にする必要があります。
この辺りは、まだ私もちゃんとしたノウハウがないので、今後も考えていきたいと思います。
以上、2つの視点で定義することで、新規制作時も効率化でき、その後の保守性も上がる色管理ができると思います。
そもそも、こういった管理を行うことを視野に入れ、デザインの段階から配色を考えていくことも、案件によってはできると思います。
私としては、サイト内で使う色を洗い出して分類できたことが一番良かったです。今後破綻が生まれないといいのですが…注意していきます。
執筆者プロフィール

ウェブデザイナー。先日、10数年ぶりにディズニーシーに行きましたが、名物の長蛇の列は変わっていないですね。待つ列が自動でちょっとずつ動く座席にでもなっていれば楽なのになぁ、と妄想してしまいました。