RSS

Sass を今すぐ実務で使おうよ!

by yamada on 2011.12.3


はじめましての tacamy です。

さて今日は Less & Sass Advent calendar 2011 の 3 日目です。

「Sass かぁ。まーたしかに便利そうだけど、
実務で使えるか分からないし自分には関係ないかな。」

とか思ってませんか・・・!?
ぜんぜんそんなことないですよ!( ・`ω・´)

その証拠に、NAVER では半年ほど前から、
新規サービスはすべて Sass を使って制作していますが、問題なく使えています。
むしろ効率化できて、CSS を書く工数が減った気もします(個人の感想です)。

小難しいテクニックは、このあとの 22 人が書いてくれると思うので(丸投げ)、
今日の記事では、Sass を実務で使うことに絞って書いてみます。

実務でSassを使うメリットって?

制作の工数が減る

CSS3 を使うときのベンダープリフィックスをいちいち自力でつけたり、
Clearfix や 画像置換の長ったらしいコードを毎回書いたり。
そういう CSS を書く上での面倒なことは Sass におまかせすれば工数削減できます。

運用が楽になる

ネストで書いていくので、コードの見通しがよくなり、他人が見てわかりやすくなります。
また、変数をうまく使うなどの工夫をすれば、後から変更が入っても一瞬で修正できます。

クオリティが一定になる

チーム内で個人のスキルの差があっても、制作物のクオリティを一定に保ちやすくなります。
Clearfix や 画像置換などの書き方が人によってバラバラになることも防げます。
Mixin に IE 向けのハックも含めておけば、変なバグにつまかることもありません。

ほんとに実務で使えるのか不安です…

IE 向けハックなどを使ったときに、変な変換をされたら困る

IE6 や IE7 向けのハック ( *property: value; や _property: value; など ) はもちろん、
IE8 向けのハック ( property: value\9; や property: value\0/; ) だって大丈夫!
IE 専用の Filter も通常のCSSと同じようにそのまま使えます。ぬかりなし。

2011/12/3 追記
IE6&7ハックの、/property: value; はエラーになるようです。
同じことが *property: value; でできるので、そちらを使いましょう。
@saucerjp さん @yomotsu さん、ご指摘ありがとうございます! (。-_-。)

導入が大変そうだし、そんなこと全員ができると思えない

ちょっと大変なのは、最初にインストールするときだけです。
どうしても分からない人には、誰かが最初だけ手伝ってあげましょう。
そもそもMacはそこまで大変じゃないし、Winも手順どおりに進めればOK。

変数とか Mixin とか、難しいことを全員に強要できないんだけど

Sass には、SASS 形式と SCSS 形式の 2 種類あるのですが、SCSS 形式は、CSS そのものです。
今までどおり CSS を書くように記述できるのでなんら問題ありません。
Sass の便利機能はプラスαとして、使える人だけ使えばいいのです。

複数人での制作で使うと、なんだか大変そう

きみ Include するひと、ぼく Mixin つくるひと。
みたいな感じで、Mixin 職人が土台となる共通 Mixin セットをあらかじめ制作しておき、
その他の人は、その Mixin を Include して使うだけ
のようにすると、スムーズに進みます。

人の書いた CSS はわかりづらいものですが、人の書いた SCSS もさらに解読が大変なので、
毎回プロジェクトごとにルールが違うと、それを都度解読するのにげんなりしてしまいます。

そこで、弊社では社内で共通のベーステンプレートを用意して、
よく使うコードを集めたコアになる部分を、Mixin 職人がこしらえるようにしています。
そうすれば一定のルールが保たれるので、案件ごとに異なるオレオレルールを紐解くなどという
心がポッキリいきそうになることはせずとも、すぐに制作に取り掛かれます。

受託案件で、運営はクライアント。
Ruby と Sass をインストールしてくださいとか言えない

ここが一番ネックになる部分ではないでしょうか。
コンパイルが必要なこと以外は、CSS と同じように編集できるということを納得してもらい、
1 日目に出てきた Scout などのコンパイラを使ってもらうのが今のところベストな気がします。
それでもダメならコンパイル後の CSS のみを納品するしかないです。

ただし、CSS のみを納品した場合には、その後のやりとりで気をつける必要があります。
クライアント側で CSS を編集し、その後、制作側で何かしら CSS を編集する場合、
CSS の Diff を見て SCSS ファイルに反映してから作業しないと、
クライアントの作業分が上書きされて消えてしまいます。
そういうことがあるので、やっぱりクライアントにも Sass を使ってもらいたいところです。
もっと Sass が普及してくると、このあたりは変わってくるかもしれませんね(希望)。

具体的に実務でどう使うと便利なの?

よく使うコードを Mixin にする

Clearfix や、画像置換など、面倒くさいけどよく使うコードを Mixin にしておけば、
@include で呼び出すだけで、使えるから本当に楽ちんです。
また、Clearfix をもっと短い新しいものに置き換えたいなどというときも、
Mixin を修正すれば、一度に置き換わるので便利です。

IE 用ハックを Mixin にしておく

たとえば、display: inline-block; を IE でも使えるようにするには、
CSS では、以下のように指定しますよね。

display: inline-block;
*display: inline;
*zoom: 1;

これを Mixin にするとこうなります。

@mixin inline-block {
	display: inline-block;
	*display: inline;
	*zoom: 1;
}

使うときは

.className {
	@include inline-block;
}

とするだけで、IE 用ハックも同時に指定できてしまいます。

この IE 用ハックを知っている人にとっては IE 用のコードを書く手間が減りますし、
知らない人にとっては、Include するだけで IE 対策が自動でできてしまいます。便利!

ベンダープリフィックスの付与は Sass に任せる

CSS3 を使うときに、ベンダープリフィックスを自分でつけるのは本当に面倒です。
でも、CSS3 用に Mixin をつくっておけば、Include するときに引数を渡すだけで
全ブラウザ向けに自動でプリフィックスつきの CSS を出力してくれます。
後から値を修正するときも、ラクラクです。

サポートするブラウザを定義する

「この案件では IE6 は対象外だから、IE6 用のハックは不要」という場合や、
「iPhone アプリの WebView で使うだけだから、
Webkit 以外のベンダープリフィックスの指定は必要ない」などという場合では、
不要なコードを減らすことで、CSS のサイズダウンができます。

最初にサポートブラウザを設定しておき、

$support-ie6: false;
$support-ie7: false;
$support-ie8: true;
$support-mozilla: true;
$support-webkit : true;
$support-opera : true;

Mixin でこのように書いておけば、

@mixin inline-block {
	display: inline-block;
	@if $support-ie6 or $support-ie7 {
		*display: inline;
		*zoom: 1;
	}
}

この場合 @if の中に書かれている内容は CSS に出力されません。

コメントアウトの使い分けをする

Sass ではコメントアウトが 2 種類あります。
ひとつは、 /* 〜 */ という普通の CSS で使うものと同じタイプ、
もうひとつは、// 〜 という 1 行コメントができるタイプです。
/* 〜 */ は、コンパイルした CSS にも出力されるのですが、
// 〜 は、CSS には出力されません。

// 〜 を使ってコメントを都度残しておけば、
他の作業者にわかりやすいソースコードになります。
CSS には出力されないので、CSS のファイルサイズも増えないし、
変なコメントを書いていても、CSS を見られただけではバレません (・∀・)

複数人での同時作業では SCSS ファイルを分割する

複数人で同時に CSS を記述する場合は、コンフリクト防止のために SCSS ファイルを分けます。
“_” から始まる SCSS ファイルは CSS ファイルとしては出力されませんが、
それをベースとなる SCSS で @import すれば、出力結果はひとつの CSS にできます。
作業用に “_yamada.scss” なんて超絶かっこ悪い名前にしてもバレません (・∀・)

Sass de 高速化!

  • @import を使って出力される CSS をひとつにまとめれば、HTTPリクエストを減らせます。
    実際の SCSS ファイルは細かく分割されているので管理しやすいので問題ありません。
  • @extend でいろんな場所で使われる同じコードをまとめれば、
    出力される CSS ファイルのサイズダウンができます。
    CSS でも手動で同じことができますが、管理しずらくなるから非現実的です。
  • 編集中はコードを見やすくするために expanded でコンパイルし、納品時に compact にすれば、
    改行やスペースが取り除かれ、CSS のファイルサイズを減らせます。

おわりに

ふぅ・・・長すぎですね。
でも、どうでしょう?実務で問題なく使えそうですよね!

Sass を使う人が増えれば、いろんな Tips や情報も増えるし、
クライアントへの説明も楽になるかもしれません。
どんどん使ってみんなで幸せになりましょうぞ。