基調講演 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つに分ける

セミナーに参加してみて

もともとSASSに対しては、現状にまったく問題がないのに、なんでCSSファイルを生成するためのSCSSというステップを踏む意味があるのか、そもそもSASSを使うための学習は無駄ではないのか、という否定的な考えでした。
そんな中で「絶対便利だから」と言われただけでは納得できなかったので、今回だまされたと思って、このセミナーに参加することに決め、その分、とても楽しみにしていたセミナーでした。

実際に参加してみて、SASSのメリットしているところに懐疑的になる部分もありましたが、圧倒的に便利な部分もありました。すなわち導入した方がいいッ！という結論に至りました。LINEでの導入実例を参考に、まずは個人レベルから始めたいと思います。