6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

CeresクリエイティブAdvent Calendar 2016

Day 7

Sass(CSSメタ言語)を使い始めた理由

Posted at

Sass(SCSS)を業務に導入して3年くらい経った?
どうやらPostCSSへ移行する時期が来てるっぽいので、そもそも何故Sass(SCSS)を使い始めたのか振り返ってみる。

Sassを知ったきっかけ

正直覚えてない。
zen-codingからemmetに乗り換えるために調べ物をしてる時に、時短技の流れで出会ったような気がする、多分。

どこを気に入ったか

当時CSSの記述で苦しく感じてた部分を網羅的に解決してくれる手法だった。

  • ベンダープレフィックスの自動付与
    • 2度と手で書かないと誓った
  • ネストとパーシャルファイルによるコードの構造化
    • 数千行のcommon.cssを運用・リファクタリングする無理ゲーから解放された瞬間
  • 念願の変数!!!
    • あのカラーコードなんだっけ?ここのフォントサイズいくつだっけ?と調べる手間が減った
    • カラーコードとタイポ周りとz-indexは変数管理することで劇的に楽になる、と最近やっと理解した。

日本語ドキュメントはほぼなかったけれど、本家サイトのドキュメントのコード部分を読むだけで十分なほど単純明快にCSSの物足りなさを補ってくれると理解できた。

mixin機能やCSS4前方互換はオマケ程度の認識だった。
extendには少し期待してた(けど大きな罠だった)

なぜSass/SCSSを選んだか

CSSに一番近い記述方法だったから、消去法で選んだ。
LESS,Stylusの方がオシャレだなーと思ってたけど、仮に業務で使うとなったら学習コストの低いSassだろうと思った。
さらにSCSSにしたのは、コーディングルールが努力義務程度のデザイナー界隈においてインデント=ネストなんて恐怖でしかなかった。

業務に導入できたきっかけ

サイトカラーを変数化すればCSSファイルを切り替えるだけでサイトの着せ替え機能が作れる?と思案していたところに、当時携わっていたプロダクトの大規模リニューアルにマークアップ担当でアサインされたので、見切り発車で導入した(気がする)。使い物にならなかったらSCSSファイルを破棄してCSSに戻れば良いだけなので、そこはもうシレッと導入した(気がする)。
サイト着せ替え機能は後日実装できればいいなと設計だけ仕込んでおいた。

どうやって浸透させた

まず警戒心を解くことから

当時のデザイナーチームはまだ3人しかいなくて、マークアップについては「見た目が大丈夫ならそれでOK」の空気があった。そこに、恐らく一度も使ったことのない黒い画面立ち上げてnpm installから始まる小難しいコマンド打つわけなので、心理的なハードルはとても高かった。

なので「超絶時短になるから!!」「駄目だったらCSSに戻せばいいし!!」と代償の低い利点をアピールし、とりあえず触ってもらうことから始めた(気がする)。

間違っても「オシャレだから/最新だから/高機能だから」などと言って導入コストを意識させてはいけない。

環境設定のフォローに奔走

当初はWin+Dwだった。NodeいれてRuby入れてSass入れてCompass入れて、黒い画面でcompass wと打つのは辛いから実行するだけの.batファイル作って作業開始時にダブルクリックすればOK状態にし、そのうちエディタ上でビルドできるからSublimeTextに乗せ変えて…と、制作環境が落ち着くまで結構時間がかかった。

PC管理者にはとてもとてもとてもお手間を取らせることとなったし、エラーが出るたびstackoverflowとgithubの英語ナレッジをググりまくるのは少し大変だった(英語ドキュメントに慣れる良いトレーニングにはなった)

今はチームにノウハウが蓄積してるのでMac&Win+ST3/Atom/Dwとマルチ対応できてる有り難さ。

サイトの着せ替え機能が当たった

折り良くエイプリルフール企画で着せ替え機能を実装する機会が巡ってきて、結果的にちゃんとした1商品として開発してもらうことができた。

初めは季節イベントや単発だけのプレミア枠のハズだったんだけど、どうやら大当たりしたらしく機能拡充を続けていった。とはいえSassがないと期待されるスピードで作れないので、この辺りになると心理的にも業務的にも制作環境におけるSassは必需品となっていた。

今はこれをJSに置き換えて完全管理画面できないかなあと思案してる。

つまり

使い始めた理由は「CSSの貧弱性を解決した(問題解決)」、現場に浸透した理由は「幸いなことに商品開発につながった(目に見える成果)」になる。

PostCSS/cssnextに移行するにあたって

2016年現在CSSメタ言語というものがデファクトスタンダードにまで昇格してきた。運に恵まれ早期の導入成功に至ったのは幸甚だったと思う。

で、Bootstrapの作者が「次はPostCSSにするわ」と言ったこともあり、やっぱりPostCSS乗り換えも早く始めたい、というかコッソリ始めてる。
現場ではすでにタスクランナーと組み合わせてるので以前ほどコストはかからない(はず)

CSS4はあと10年は来ないだろうけど、「デファクトスタンダードだから」では学習の動機として薄い。CSS3と同じように「実質的にサポートしてる」が来た時には十分書けるようになっていたいかな。

そしてやっぱり顔を出してくるJavascript

CSSメタ言語をどれだけ使いこなしたところで最後はただのスタイルシート。
多少条件分岐や関数が使えてもプログラミング言語ほどの柔軟性もなければ深度も浅い、と思ってました、Gulpfile.js上にJSの記述でmixinを定義できると知るまでは。

まだ手元で検証してないのでどんな肌感かわからないけど、SassScriptで無理やりプログラムっぽい真似しなくても良いってことのようで非常に期待してる。
反面、とうとうCSSにすらJSが必要な時代になってしまったようで、10年以上何かと避けてたJSというものを根本から身につけなければいけないくて戦々恐々としてる。

来年の抱負

2017年はCSSのためにJavascriptのスキルアップに努めたいと思います。
今度はjQueryに逃げられないので必死です。

6
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?