昨日、CSS Nite LP, Disk 26に行ってきました。今回のテーマはCSS Preprocessor Shootout。
CSSの設計をどうすべきかというテーマの基調講演ののち、前半はCSSプリプロセッサ SASS/LESS/Stylusそれぞれのお話、中盤はそれらを使うためのツールのお話、後半は実務で使われている企業の方々の事例、最後にCSSデザインの過去・現在・未来についてと、豪華登壇者による全10セッションでした。
時間にして5時間半の長丁場でしたが、面白くて興奮しすぎて全然苦じゃなかった笑。参加した人には後で資料のフォローアップがある(確か3ヶ月後くらいには参加してない人向けにもオープンになるはず)ので、ここでは自分が気になった部分のざっとした内容と感想をめも。
登壇された方やプロフィールなど > http://lp26.cssnite.jp/
予習用の参考動画 > http://cssnite.jp/afterdark/cpi/vol01/
Twitterまとめ > http://togetter.com/li/435908
基調講演: CSSの設計
CSSの設計をどうしていくかというお話。CSSの設計はページ設計の段階から関係してくるので上流から関わっていく必要がある。「枠とモジュール」というOOCSSの考え方をベースに9個ほどの項目が紹介されました。
- OOCSS(Object-oriented CSS)という考え方。[参考]OOCSSとSASS http://takazudo.github.com/blog/entry/2012-12-10-oocsssass.html
- 枠とモジュールという考え方で設計する。クラス名はモジュールを起点につけていく。クラス名は抽象的すぎず具体的すぎない名前が良い。
- モジュールの一覧を作る。
- 亜種は「itemblock」「itemblock2」のように数字をつける命名規則にしている。1番目のものに1と書かないのは、2番目があるとは限らないから。
- 余白のルールは単純に。マージン用のモジュール(便利クラス)を作るのが単純でおすすめ。※ただし、あくまでも微調整用のクラス。
- HTML要素にマルチクラスでクラスをたくさん書いてしまうと、スタイルを直に書いているのと同じになっちゃう。共通する部分(モジュール base。例えばボタンのベース)に、スキン(色等)を当てる方針が良い。
- jQuery UIのクラス名は階層構造(base-inner-inner2)になっていて、ガチガチに名前を固めているので色んなとこに入れても崩れる心配が無い。
パフォーマンスから考えるSass/Compassの導入・運用
サイバーエージェントが作った女性だけの完全匿名コミュニティガールズトークでの事例を踏まえながらのSASSの紹介でした。ガールズトークではページスピード・開発スピード、2つを両立することが必要だったことから、SASSを導入したそう。
- enja-ossという翻訳コミュニティでSASSのリファレンスの翻訳が始まった。https://github.com/enja-oss/Sass
- 入れ子が深くなるとセレクタが長くなる → 名前解決に時間がかかるから駄目というよりは、詳細度が高くなるから微妙。=再利用しにくいクラス。
- CSSのネストは3階層まで。
- 疑似要素の初期化にextendを利用。
- 『すべてのクラス名はコンテンツ派生である必要はない。』by twitterのニコラスさん
- スプライト画像の管理はすごくめんどくさい。→CSS SpriteのためにCompassを使った。CSS Spriteには [1]画像を生成する [2]background-positionを生成する の2つのステップがある。Compassではローカル環境の画像ファイルが取って来れるので、各画像が入っているフォルダを用意し、それらをcompassでスプライトシートにコンパイルするmixinを作った。[参考]http://t32k.me/mol/log/spriting-with-compass/
- スタイルガイドはstyledocco http://jacobrask.github.com/styledocco/ を利用して作った。スタイルガイドをどう作るかを考えていく=コンポーネントという概念を考えやすくなったらしい。
- 『セレクタは詩である』
LESS is MORE: CSSプリプロセッサをシンプルに使う
LESSの紹介セッション。LESSの一時期開発が危ぶまれたLESSだが、最近は開発が安定しているとのこと。
- SASSと違うところは、lessはサーバーサイドでも、クライアントサイドでも実行できる。クライアントサイドでの実行は、変換の時間がかかっちゃうので、本番環境ではお勧めしない。
- ネストでDOMツリーっぽく書けるのは便利だが、詳細度が上がる(この話はSASSのところでも出てきた)。便利なものを使うのはいいが、その不都合があった場合に自分が修正できるか?裏側を理解しておくことが大切。
- :after、:beforeでclearfixの要素を作る。疑似要素でクリアする。
- 『ちゃんとCSSを書け!』by 斉藤さん
- サイバーは8割SASS。プロジェクト間でコードの使い回しができるから。
- スケーラブルでモジュラーなCSSアーキテクチャに関するSMACSS(smacss.com)っていう電子書籍の日本語訳が2月くらいにでるよ。
Stylusが目指す"CSSプリプロセッサ"
Stylusは後続であることもあって、SASSとLESSのいいとこ取りをしているそう。SASSがCSSより複雑なことを実現可能にするメタ言語的な方向を目指しているのに対して、LESSはプロプロセッサ的。そもそも思想が違うので比較すると真逆のことを言うことになる。Stylusはその点、SASSのような機能を提供しつつもCSSっぽさを保ったCSSらしい高機能言語といえるらしい。
CodeKitで始める次世代Web制作
新世代エディタで作る、プリプロセッサー環境構築術
Dwとvim、Coda2、Sublime Text2の4つのエディタでの環境構築の紹介。
- DwはCSSプリプロセッサに未対応。
- Coda2はエディタ部分が貧弱。膨大な行のソースコードを展開しようとするともっさり。
- Sublime Text2にCSSが早く書けるようになるhayakuというプラグインがあるらしい。 http://inkdesign.jp/notes/2012/11/27/Hayaku-changed-my-world.html
- SublimeについてはAfterDarkの回の映像を参照。http://cssnite.jp/afterdark/cpi/vol05/
- おすすめは Coda2(ファイルの管理などにつかう) + Sublime Text2(編集につかう) + CodeKit + SASS + Compass
環境に合わせて快適コンパイル生活
GUI系の環境とCUI系の環境について。ツールなどが色々と紹介されました。
- WPでSassやLessが使いたいなら、Jetpack http://jetpack.me/
- 静的なHTMLやJS,CSSだけならAnvi for Macを使うと楽。
- MIXUTRE(http://mixture.io/)というツールも開発されている。CodeKitより高機能っぽいので期待。
- SASSなどの環境+ST2+ビルドツールを入れるだけでいい。
GREEを支える技術フロントエンド版
毎日の料理のためのSass
クックパッドでのSASS導入事例。ユーザーへ体験をどう伝えて行くかを考える(UIのリニューアルとか)サービスデザイン部のデザイナーの方のお話。
- クックパッドのエンジニアは海外の方もいらっしゃるのでガイドラインは基本英語
- クラスのつなぎはアンダースコア。けどハイフンがいいなーと思っている。
- Saraという専用UIフレームワークがあり、UIコンポーネントを共有できているようになっている。Sara → 料理が乗る「皿」の意味。パッケージ管理システムで全開発者がベースとして入れる。
- SASSの変数で、テーマカラーとなるカラーチップを定義している。
- SASSにしたことでABテストがやりやすくなった。
- 変数化する事によってコードレビューとデザインレビューで一気に行う。→ サービス開発のためのボトムアップ型のデザインガイドライン。
- おいしそうなデザインを目指す。= 青は使わない。逆に開発環境ではあえて青を使う。
- 3月にUIデザインのパターン化の本が出るらしい。
CSSプリプロセッサーの登場・発展から考えるCSSデザインの過去・現在・未来
こたろっくさんを中心に、ずどさん、よもつさんによるCSSの過去、現在、未来について考えるセッション。
- コーディングするにもWebアプリは段違いに複雑。モジュールを並列に積むだけで解決できていたのは、ドキュメントベースのページの話。
- CSSプリプロセッサが使える事がもう求人の要件に入ってきている。ツールを使えるというよりは、思想を理解している人が求められているのではないか。
- 大規模なものを作るときは管理的な機能を使わないと辛くなる。
- 初期のiPhoneにはネイティブアプリはなく、すべてWebアプリだった。ジョブズがそういう方針だったが、パフォーマンスが出なかったため、現在のネイティブアプリの方針になったという経緯がある。
- Webはドキュメントプラットフォームからアプリケーションプラットフォームへ。あらゆるソフトウェアがWebになる。もちろんドキュメントとしてのWebも残る。環境はより多様に。
- CSSプリプロセッサーへの流れは、テーブルレイアウトからCSSレイアウトへの変化に匹敵するような、大きな変化である。
- Chromeのdevtoolsが先走ってSASSをサポートしている(笑)
- 今後はCSS自体が進化して行く。技術の仕様が決まるのは、今迄使われていていたものが結果的に仕様になる。今、考え方を理解しておく事が必要。
かんそう
今回のCSS Niteはほんっとに面白かった。私自身はCSSプリプロセッサについてはSenchaのスタイリングでちょこっと調べて変数使ったことがあるくらいで、普段はちまちま生のCSSを試行錯誤しながら書いてる。それこそクラスがごちゃっとなって混乱したり。だから、基調講演の枠とモジュール、命名規則の話はめちゃくちゃ為になった。
GREEとクックパッドの事例は、新しい技術を取り入れるのも早いし、高速化への配慮やデザインガイドラインの整備、運用にもびしっと乗ってて、走り続ける最先端の現場ってすげぇとため息がでるほどだった。理想があの現場にある感じがした。
最近よく耳にするCSSプリプロセッサだけど、最先端っぽい企業が取り入れてるのかと思ったら、予想以上に会場の1/3の人がすでに実務でCSSプリプロセッサを使われていて、もう若い技術なんかじゃなく現場に取り入れるべき技術じゃないかと思った。使おうと思えば使える状態にはなっておきたいな…
セッションを通してみなさんがおっしゃっていたのは、CSSプリプロセッサは道具でしかなく、使ったからCSSがうまいことなるわけじゃないということ。『ちゃんとCSSを書け』という言葉が何回も出てきました。設計思想を理解して実践することが大切。明日からモジュールを考え直さなくちゃ。最終成果物がCSSなら、しれっとSASSを使っていくのもありかもしれん。やる気でたー(`・ω・´)