- 講演者
（敬称略） - Why Sass? ：谷 拓樹（サイバーエージェント）
- CSSがもっとラクに書ける！これから始めるSassの書き方：柴田 大樹（アンコピ）
- Sassにもっと便利な機能をプラス！ Compassを使ってラクしましょ♡：黒野 明子（crema design）
- Sass/Compassの導入と環境構築：森田 壮（ソウラボ）
- コピペで使える！変数とmixin！：坂巻 翔大郎（ピクセルグリッド）/ 山田 敬美（ピクセルグリッド）
- Sass/Compass よくあるトラブルと解決方法・回避方法：西畑 一馬（まぼろし）/ 木村 哲朗（まぼろし）
- Sassの日常の運用：富田 梓（LINE）
- HTMLテンプレートの設計：高津戸 壮（ピクセルグリッド）
- 開催日
- 2014年2月15日
- 場所
- ベルサール九段
基調講演 Why Sass?
なぜ、あえてSass？
潜在意識として、
デザイナー視点では、Sassは不要に感じている。
プログラマー視点では、CSSは貧弱に感じている。
Sassは何をしてくれる？
Sassは、CSSをより強力にするための言語で、Rubyでできている。
と聞くとRubyに無知な自分にとっては、難しいイメージだが恐れるに足らず。従来のCSSの書き方で問題ない(Sass バージョン3から)。
Sassはどうやって使うのか？
拡張子は、.sass or .scss
↓ コンパイル（変換）
.css
なぜ、Sassを選ぶのか？
ほかにも、less / stylus とかもあるけど、なぜSass？
- 日本語ドキュメントが多い
- 安定している
- compassというフレームワークがある
Sassはただのツール
コンパイル後のCSSを想像してSassを書く
コンパイル後のCSSが汚い場合は、Sassの書き方に問題あるということ
CSSがもっとラクにかける！これから始めるSassの書き方
なぜSass？ → ラクに書けるから
入力の手間を省く
- 共通のセレクタ （心の声）うーん、クラス完結させていつも書いているから、現状そんなに手間じゃない。
- 同じ値(ささいな色もカラーの値は変数化しておくといい)ちょっと便利かも。でも一括置換でいいんじゃね！？
- 同じプロパティと値（mixin と include）mixin class名を並べればいいんじゃね！？お？ @mixin の引数に変数を追加できるだって？ちょっとやばい。
- セレクタのグループ化@extend 一見よさそうだけど、上書き用であればそれってどうなの？そうじゃないよね。
CSSをまとめる
複数ファイルが一つのファイルになるのは、すごい！
計算できる
色の微修正、いいね！グラデとかもできて、反転とかもできるといいな。
Sassにもっと便利な機能をプラス！Compassを使ってラクしましょ♡
compassって何？
Sassだけではできない機能がセットになっている。
- 便利なMixin集
- vendor prefixes
- CSS Sprite
- data URI scheme
その他のたくさんの機能はCompass Helpersで確認。
CSS Spriteとdata URI schemeはとくに感動したッ！これだけでCompassを取り入れる価値あるッ！
Sass/Compassの導入と環境構築
導入方法は、他サイトや教則本を参考にするとして、衝撃だったのは、その手軽さ。セミナー内で環境をインストールし、コンパイルしてCSSファイルを出力できた！
コピペで使える！変数とmixin！
かわいいからすべて許せる内容でした。
お友達になりたいわー。
Sass/Compassよくあるトラブルと解決方法・回避方法
導入の障害を乗り越える方法
クライアントに環境がないときはどうする？
- 調整用のCSSファイルを別途用意する
- コンパイル後のCSSファイルを直接さわってもらう
- がんばって使ってもらう
いずれにせよディレクションのお話
SCSSファイルって納品するの？
原則として納品する
文字コードが非UTF-8
回避方法がある。
Sass/Compass の御法度
ネストの多用
ネストが深すぎると・・・これはひどい
ネストは3階層まで、とルール付けをして制限をつけるといい。
extend の多用
運用面で破綻してしまいがち・・・これはひどい
クラスやmixinをつかう
ただし、mixinは、extendとは違いサイズ要領が大きくなるので、扱い注意。
@media の中では @expand はつかえない
IE9 以下では4,095個までしかセレクターを認識しない
そもそもそんなにセレクターを書いている時点で設計がまずい。
うまく運用するために
- メンバーを思いやる
- 使用方法をコメントに記す
- 関数もおなじ
- スプライト画像の肥大化
画像を使いすぎるとスプライト画像が肥大化する
iPhoneのSafariではおおよそ500万画素以上のGIF/PNG/TIFFは表示できない
Androidは機種による
↓
スプライト画像を分割するなど一枚にあつめすぎない
できるだけ画像を使わない
アイコンをフォント化
かゆいところに手がとどく
- Compassで複数のファイルに書き出せる
- スプライト画像のファイル名を綺麗にできる(キャッシュバスター)
- スプライト画像コンパイル時のプラグインをchunky_png から oily_png にする
「次」へのステップ
レスポンシブルなWebデザインを容易に作る Bootstrap / Foundation /Bem
バージョン管理 bundler
Gruntでもっと便利に(Compassより柔軟)
Sassの日常の運用
LINE株式会社での導入事例をサンプルに、職種や環境、技術レベルの異なる複数の作業者がかかわる環境で、どのように導入し、運用を続けているかを、紹介していただいた。
2011年6月から実用できるかを検査が始まり、実用できると判断後はチーム全体で導入の開始が始まり、現在は問題点のフィードバックとライブラリへの反映を行っているとのこと。
詳細はLINEのエンジニアブログに紹介されていて大変興味深い。 LINE Engineers’ Blog NAVERでのSassの使い方
HTMLテンプレートの設計
compassを導入する際には、設計をしっかりしておく必要がある。そうしないと運用が破綻しかねないので注意が必要だ。
そんな中で3つの概念モデルを紹介していただいた。
OOCSS(Object Oriented CSS)
オブジェクト指向っぽく考えて整理しよう。
レイアウトに依存したCSSはダメ(なぜなら上書き合戦となるから、もしくはコピーしなければいけないから)
↓
レゴみたいに考える
↓
スキン(共通項目を一つのモジュールに)
BEM(Block Element Modifier)
BEMというワードは、いろんなケースで使われその意味が変化するが、ここではクラス名のこととして説明。BEMでは、クラス名の命名規則を厳格にしているのが特徴。
ややこしく、クラス名が長くなるデメリットがあるが、設計思想 / ルールの統一ができるのは大きなメリット。これを導入することで得られる4つのポイント。
- 高速な開発が可能
- プロジェクトの寿命を延ばせる
- チームによる実装を可能に出来る
- コードの再利用を可能にできる
SMACSS(Scalable and Modular Architecture for CSS)
CSSルールを5つに分ける
| Base | サイトのデフォルトスタイルを定義する |
|---|---|
| Layout | サイトレイアウトの枠組み、およびそれを調節するための仕組み |
| Module | レイアウトの中にモジュールをいれていくサブクラス（OOCSSのスキン） |
| State | 状態ルール（BEMのクラス名ルールと同じ） |
| Theme |
セミナーに参加してみて
もともとSASSに対しては、現状にまったく問題がないのに、なんでCSSファイルを生成するためのSCSSというステップを踏む意味があるのか、そもそもSASSを使うための学習は無駄ではないのか、という否定的な考えでした。
そんな中で「絶対便利だから」と言われただけでは納得できなかったので、今回だまされたと思って、このセミナーに参加することに決め、その分、とても楽しみにしていたセミナーでした。
実際に参加してみて、SASSのメリットしているところに懐疑的になる部分もありましたが、圧倒的に便利な部分もありました。すなわち導入した方がいいッ！という結論に至りました。LINEでの導入実例を参考に、まずは個人レベルから始めたいと思います。