エンジニアの栗山です。
最近になって、社内CSSフレームワークを作ったので、その共有をしたいと思います。
CSSフレームワークほしい…
まずCSSフレームワークと聞いて思い浮かべるのが、Bootstrapではないでしょうか。 これは非常に便利ですよね。デザインが苦手なエンジニアでも簡単に見栄えのいいサイトが作れます。 ぜひともこういったCSSフレームワークを使いたいところですが、これをそのまま使うとデザインがBootstrapそのものになってしまうので、その会社そのサービスにカスタマイズしたCSSフレームワークが必要になります。 そこでベースとなるCSSフレームワークを選定し、それをカスタマイズして社内CSSフレームワークを作ることにしました。(一からCSSフレームワークを作るのは大変なので)
ベースとなるCSSフレームワークの選定
Semantic UIやKubeなど、候補に上がったCSSフレームワークとしてはいくつかありますが、 人気とデザインの良さからPureとFoundationが最終候補に残りました。 Foundationは機能が豊富でよさそうだったのですが、ゴリゴリのSassで書かれていたため、これをデザイナーさんがカスタマイズするのはちょっとハードルが高そう。 対してPureはCSSのみで作られていてカスタマイズが非常にしやすい。 ということでPureをベースのCSSフレームワークに選びました。
ちなみに実際にPureをもとにCSSフレームワークを作ったのはうちのデザイナーさんで、私は社内CSSフレームワーク周りの環境整備をやりました。
Sassが使いたい
いまどきCSSプリプロセッサ使ってないとかマジでなくね？ということでSassを使うことにしました。 Sassを選んだ理由はLESSやStylusよりもユーザ数が多く、またScss記法になってCSSに近い記法なりデザイナーさんも親しみやすい点からです。 PureはCSSで書かれていますが、そのcssファイルをSassファイルにしてSassで書けるようにしています。
(あとCSSフレームワークでデザインが全て完結するわけではなく、そのページ特有のデザインのためにそのページ用のCSSを用意することがあります。 そのCSSもSassで書くようにしました。)
SassといえばCompassですが…
Compassは有名ですが、ちょっと重厚です。 CompassでやれることのほとんどはGruntプラグインで実現できます。 またCompassはSassのコンパイルが非常に遅いです。 しかしCompassのMix-inは便利なので使いたい…。 そこでBourbonを使うことにしました。 Bourbonは安心と信頼のthoughtbotが作っている"A simple and lightweight mixin library for Sass."です。 Mix-inも十分揃っていますし、ただのSassファイルの集合なのでコンパイルも非常に速いです。
Grunt！
SassのコンパイルやCSSの結合圧縮、CSSスプライトの作成等々、フロントエンドのもろもろのタスクを自動化してくれる便利な味方、Gruntも使うことにしました。 Gruntのプラグインは色々入れていますが、主なやつは以下です。
- Sassのコンパイルのためのgrunt-contrib-sass
- CSS Lintを実行するためのgrunt-contrib-csslint
- CSSを圧縮するgrunt-contrib-cssmin
- CSSを結合するgrunt-contrib-concat
- LiveReloadのためのgrunt-este-watch、grunt-contrib-connect
- Gruntの実行に失敗したらポップアップで通知してくれるgrunt-notify
grunt-este-watchはPCの負荷が少なくて非常に良いです。 あとgrunt-notifyはエラーにすぐに気付けて地味に便利ですね。
また巷で言われるように、タスクが多くなってくるとGruntfile.jsが結構きつくなってくるので、gulpを入れようか考え中です。。
スタイルガイド、いいよね
格好いい社内CSSフレームワークを作っても、そのスタイルを適用したらどんなデザインになるのかが簡単に分からないと、みんな使ってくれません。 簡単に言えば http://getbootstrap.com/css/#forms みたいな画面が作りたい。 こういうのを巷ではスタイルガイドと呼ぶようです。 スタイルガイドは有名どころでは、StyleDoccoや、KSS、Kaleiがあります。 エニグモでは、スタイルガイド自体のデザインも出来るKSSを使うことにしました。 KSSはちょっと導入が面倒なのですが、それを簡単にするkss-nodeというものを使っています。
CSS命名ルールを決めたい
CSSのクラス名の付け方とか結構迷いますよね。
最近ではOOCSSとかBEMとかSMACCSとかが出てきています。
エニグモではシンプルで分かりやすい(けどクラス名が長くなる)BEMを使うことにしました。
ただ厳密にBEMを適用するとクラス名が長くなってしんどくなるのでほどほどに取り入れています。
この辺の命名ルールはまだ模索中です。
まとめ
他の会社でも社内CSSフレームワークを作りたいという欲求はあると思います。 ただ一から作るのは大変なので、うちのようにベースとなるCSSフレームワークを用意するとよいのではないでしょうか。
また今回いろいろ環境は整えて前と比べてモダンな感じになったのですが、実際に社内CSSフレームワークを使っていく運用はまだ始まったばかりです。 特に大変なのが、既存のCSSと今回作った社内CSSフレームワークの共存です。 既存のCSSが思わぬ影響を及ぼしたりして地道な調整が必要になるのですが、そこはデザイナーさんが頑張っております。
プロジェクトの寿命が長いとどうしても開発環境がレガシーになってきてしまいますが、そうなると生産性やメンテナンス性に影響が出てしまうので、随時新しい技術を取り入れてモダンな開発環境を保っていきたいと思います。
