ナビ

Sass(CSS Nite LP32)

wrote :

講演者
(敬称略)
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での導入実例を参考に、まずは個人レベルから始めたいと思います。