先日@mah_labと下北沢OSSカフェにて開催したSass+Compass勉強会の前後から、個人的な新規制作物は全てSass+Compass環境での制作に切り替えました。

実際にはSassではなく、Scssでの導入を行なっていますが、実際使ってみて、運用してみての所感をまとめてみたいと思います！

制作環境・手順の変化

メインエディタが元々Coda2であったことから、Coda2内蔵コンソールを使用して自動監視で制作しています。

所謂「黒い画面」に対しては、アレルギーこそないものの、苦手意識を持っている部分もあり、不安な部分もありましたが、その日の作業開始時に

compass watch

を入力するだけなので、特に難しくもなく使えています。

それでも不安な人は、プロジェクト立ち上げの際にシェルスクリプトを作り、ダブルクリックで起動できるようにしても良いかもしれませんね。

シェルスクリプトの例（compass_watch.command）

#!/bin/bash
MY_DIRNAME=$(dirname $0)
cd $MY_DIRNAME
compass watch

上記を改行コードLFで保存し、実行権限を付ける。

Windowsの人は拡張子を「.bat」にして、

compass watch

と書いて保存するだけなのでもっと簡単です。

コンソールでの入力や、コマンドプロンプトでシェルスクリプトやバッチファイルを作ったりする方法であれば、エディタも選ばないので、使い慣れたエディタが使えるのが良いですね。

Coda2はコンソールですが、Sublime Text2であればSass/Compassのコンパイルができるパッケージもあるようなので、それを使うのもアリですね。

Scoutも試してはみたのですが、コンピューター全体が少し重くなるような気がします。Adobe Airで動くので、環境を選ばないというメリットと、手軽に導入できるメリットがあるので、良いなあとは思いますが、個人的にはターミナルがイチオシです。これをきっかけに黒い画面に対するアレルギーがおさまるとかおさまらないとか。

というわけで、これから導入する人は、使い慣れたエディタの追加機能でコンパイルすることを調べて、ダメならターミナル（コマンドプロンプト）。CUIでの導入が不安ならScoutみたいな感じで導入してみるのが良いのではないでしょうか。

変わったこと

コマンドを1行打ってから作業をはじめるようになった。

変わらなかったこと

監視の起動さえすれば特に気にすることはないです。

CSSの記述の変化

CSSの記述というか、実際にはScssを記述することとなり、記法を覚えることを目標としながら記述を行いました。

変数をはじめ、mixinやextend、CSSの入れ子など、特徴的な機能を積極的に使いながら初めてのScssファイルを作りました。

Scssであれば、CSSをそのまま書いても、CSSとして書き出されるので、少しづつ習得していくことができるのが大きなメリットです。

まずは変数で、メインカラー、サブカラーなどを定義しして呼び出す機能を使ってみると良いかと思います。
基本的には似た記述は極力まとめていくというのが基本の使い方になるので、経験則の部分が大きくはなるのですが、

  • カラー設定、基本的なマージン設定を変数で。
  • 入れ子を使って可読性を高める。
  • 面倒なベンダープレフィックスを@includeで。
  • 3回同じ表現をするならmixinにする。（先日の勉強会で上がった内容です）

このあたりから手を出すのが良いのではないでしょうか。

これだけでも確実に記述する行数が減り、作業時間が短縮できましたし、メンテナンスもしやすくなりました。

特にHTMLのモックアップを作る時に、ミックスインの中の数値だけいじれば全体が変わったりするなど、凄く便利です。

グリッドレイアウトでも、グリッドの横幅を変数にするなど、まとめられるものをまとめるという意識を持つと良いのではないでしょうか！

あと、コメントアウトが使いやすくなります。

/* コメントアウト */　はCSSとしても出力されますが、//コメントアウト は出力されないので、

$displayWidth : 960px; // 全体のmax-width
$mainWidth  : 940px; // メインコンテンツの横幅

とか書いてもCSSには表示されないので、CSSの容量を気にせず、細かいコメント付けが可能なのが一番のメリットかもしれません。

変わったこと

少しの意識で大きく作業時間が変わる！

extendやeachなどを使うなら習得コストが必要。

変わらなかったこと

Scss形式で書くならこれまでのCSSの記述ルールが生かせる。

導入にあたってのハードル

個人で作っているものに関しては、もちろん障壁になるものはなく、すぐに導入できて、活用もできる手応えを早い段階でつかむことができました。

会社などで導入を考えた場合には、会社の規模や組織によって様々なハードルがあるかもしれません。

  • チーム内（もしくは個人）の練度の問題
  • 記述ルールなど、ガイドラインを策定するためのコスト
  • 受託でクライアントがCSSを触る可能性がある場合

このあたりが主なハードルでしょうか。

周りを見渡してみると、Web制作会社であれば、練度の問題はクリアしやすいかとは思いますが、印刷業者のWeb担当者さんなんかだとチーム全体という意味では難しいところもあるのかなあといった印象です。

ただ、変数やmixinなどの機能はわかる人だけが使えばいい部分が多く、「わからなければ聞いてください！」と言えるチームであれば、大概杞憂に終わるのではないかと思います。

ドキュメントを自力で作るのは大変ですので、CSS HappyLifeさんの記事や、Sass入門あたりを教科書として周知するなどが良いのではないでしょうか。

  • 受託案件でクライアントもCSSを編集する場合が一番のネックですが、
  • クライアント側担当者向けにSassの設定と講習を行う
  • 納品時にはexpandedでコンパイルする設定にし、その後はCSSの編集のみにする
  • Diffを見てその都度反映してから作業する
  • そもそもクライアントに編集させない

ざっと考えて、こんな選択肢になると思います。

これはクライアントとの関係性で判断するしかありませんが、クライアントも含めたチームとして最善の策を考え、最善の判断をしていくしかないのかなあと思います。

導入さえしてしまえば、それぞれの習熟度にあわせて良い感じに使えるのが一番のメリットだと思いますので、是非導入して、良いSassライフを送ってみて下さい！