hiromitsuuuuu.log();

to see more to see.

CSS Nite LP, Disk 26「CSS Preprocessor Shootout」に行ってきためも。

Dev 勉強会レポ

昨日、CSS Nite LP, Disk 26に行ってきました。今回のテーマはCSS Preprocessor Shootout。
CSSの設計をどうすべきかというテーマの基調講演ののち、前半はCSSプリプロセッサ SASS/LESS/Stylusそれぞれのお話、中盤はそれらを使うためのツールのお話、後半は実務で使われている企業の方々の事例、最後にCSSデザインの過去・現在・未来についてと、豪華登壇者による全10セッションでした。

f:id:hiromitsuuuuu:20130112195338j:plain

時間にして5時間半の長丁場でしたが、面白くて興奮しすぎて全然苦じゃなかった笑。参加した人には後で資料のフォローアップがある（確か３ヶ月後くらいには参加してない人向けにもオープンになるはず）ので、ここでは自分が気になった部分のざっとした内容と感想をめも。

登壇された方やプロフィールなど > http://lp26.cssnite.jp/
予習用の参考動画 > http://cssnite.jp/afterdark/cpi/vol01/
Twitterまとめ > http://togetter.com/li/435908

基調講演: CSSの設計

CSSの設計をどうしていくかというお話。CSSの設計はページ設計の段階から関係してくるので上流から関わっていく必要がある。「枠とモジュール」というOOCSSの考え方をベースに９個ほどの項目が紹介されました。

  • 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の紹介でした。ガールズトークではページスピード・開発スピード、２つを両立することが必要だったことから、SASSを導入したそう。

  • enja-ossという翻訳コミュニティでSASSのリファレンスの翻訳が始まった。https://github.com/enja-oss/Sass
  • 入れ子が深くなるとセレクタが長くなる → 名前解決に時間がかかるから駄目というよりは、詳細度が高くなるから微妙。＝再利用しにくいクラス。
  • CSSのネストは３階層まで。
  • 疑似要素の初期化にextendを利用。
  • 『すべてのクラス名はコンテンツ派生である必要はない。』by twitterのニコラスさん
  • スプライト画像の管理はすごくめんどくさい。→CSS SpriteのためにCompassを使った。CSS Spriteには [1]画像を生成する [2]background-positionを生成する の２つのステップがある。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 斉藤さん
  • サイバーは８割SASS。プロジェクト間でコードの使い回しができるから。
  • スケーラブルでモジュラーなCSSアーキテクチャに関するSMACSS（smacss.com）っていう電子書籍の日本語訳が２月くらいにでるよ。

Stylusが目指す"CSSプリプロセッサ"

Stylusは後続であることもあって、SASSとLESSのいいとこ取りをしているそう。SASSがCSSより複雑なことを実現可能にするメタ言語的な方向を目指しているのに対して、LESSはプロプロセッサ的。そもそも思想が違うので比較すると真逆のことを言うことになる。Stylusはその点、SASSのような機能を提供しつつもCSSっぽさを保ったCSSらしい高機能言語といえるらしい。

  • Stylusの一番の特徴は言語デザインが柔軟なこと。いろいろな書き方ができる。
  • エラーレポーティングがSASSやLESSより親切でわかりやすい。
  • Stylusにもnibというmixin集がある。
  • Data URIへの展開をサポート。CSS Spriteをサポートするプラグインも。
  • まだ若いプロダクトだが、reworkっていうプロダクトが作られているそう。プレーンCSSに回帰していて、必要な機能（extendとか）だけをプラグインみたいに取り込む形。

CodeKitで始める次世代Web制作

GUIでSASS、LESS、Stylusを使うためのツールCodeKitの紹介。

  • http://incident57.com/codekit/
  • Mac専用アプリ。LION以上で動作。SASS/LESS/Stylusが使える。
  • 有償で、25ドル。現在円安なので2000円くらい？
  • CodeKitでcompassを利用するには、プロジェクトに対してcompassの設定が必要。
  • compassにはbase64に変換してくれるmixinがある。
  • CodeKitでは、CSSプリプロセッサの利用以外にも、JSのminifyや、JSの文法チェックや、ファイルの結合、画像最適化もできる！！※画像最適化はImageOptimなんかのほうが高機能なのであまり使うことはないかも。

新世代エディタで作る、プリプロセッサー環境構築術

Dwとvim、Coda2、Sublime Text2の４つのエディタでの環境構築の紹介。

環境に合わせて快適コンパイル生活

GUI系の環境とCUI系の環境について。ツールなどが色々と紹介されました。

GREEを支える技術フロントエンド版

GREEでのSASS導入事例。GREEのプラットフォームでは、開発効率とグローバル化に課題があったそう。

  • 海外では回線が細いので、グローバル化において表示速度改善は重要課題。
  • スマホやタブレットのUIはパターン化しやすい。＝ コンポーネント化。疎結合な設計を重視。
  • 良いコードの下地は良いデザインルールから
  • 管理しているファイル数が多いため、compass watch は基本的に使わない。都度シェルをたたく方式。
  • PHPでベンダーを判定して、ベンダーごとに必要なCSSだけを遅延ロードしている。高速化を命題にしているので、それぞれのベンダープレフィックスを書いていると冗長すぎる（１行でも減らしたいため）。

毎日の料理のためのSass

クックパッドでのSASS導入事例。ユーザーへ体験をどう伝えて行くかを考える（UIのリニューアルとか）サービスデザイン部のデザイナーの方のお話。

  • クックパッドのエンジニアは海外の方もいらっしゃるのでガイドラインは基本英語
  • クラスのつなぎはアンダースコア。けどハイフンがいいなーと思っている。
  • Saraという専用UIフレームワークがあり、UIコンポーネントを共有できているようになっている。Sara → 料理が乗る「皿」の意味。パッケージ管理システムで全開発者がベースとして入れる。
  • SASSの変数で、テーマカラーとなるカラーチップを定義している。
  • SASSにしたことでABテストがやりやすくなった。
  • 変数化する事によってコードレビューとデザインレビューで一気に行う。→　サービス開発のためのボトムアップ型のデザインガイドライン。
  • おいしそうなデザインを目指す。＝ 青は使わない。逆に開発環境ではあえて青を使う。
  • ３月に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を使っていくのもありかもしれん。やる気でたー(｀･ω･´)