実践Sass 前編

自己紹介
NHN Japanという会社で
MEをやっています

@a_t

共著しました
電子書籍ですが
ブラウザで見れます
今すぐアクセス！

実践Sass
• 前編
• 導入、運用してわかった
ポイントについて解説
➡ Sassを使い始めた初級者向け

実践Sass
• 後編
• 社内ライブラリを作って気づいた
ポイントを解説
➡ ライブラリを作ろうとしている
中級者向け

前編で扱う内容
• NHN JapanでのSass導入
• 運用時のポイント
• コーディングのポイント

導入した環境
• MEの6-7割がMac
• エディターもバラバラ
• 基本的には全員CUIで導入
※全員が黒い画面に使えるわけではない

コンパイル設定の共有
CSSにはない「コンパイル」が必要

Sassのコンパイルコマンド
sass
--watch [sass dir]:[css dir]
--style [圧縮形式]

プロジェクトのwikiで共有

➡ 忘れることもある

Compassで解決

Sassのフレームワーク

ライブラリの他に、Sassには
ない拡張機能を利用できる

設定ファイル：conﬁg.rb

対象ディレクトリや
圧縮形式を書いておく

プロジェクトごとに
ルートディレクトリにコミット

Compassがあれば
compass watch

全プロジェクトこれでOK！

環境差異
出力される@charsetが違う
@charset "utf-8"、
@charset "UTF-8"とか
おかげでCSSがコンフリクト

詳細な原因は不明

Win/Macの違い
rubyのバージョンの違い?

あと勝ち解消でOK

CUIが苦手な人には
GUIツールもある
プロジェクトでGUIとCUIが
混在しても問題ない

Scout
• 無償

• Compassも対応

• サイトからDLできるver.ではconﬁg.rbが読めない

• githubの最新版は、conﬁg.rbとSass3.2対応

• Sass3.2の対応が遅かった
（一昨日ようやくリリース）

Compass.app
• $10（paypal支払い）
• インストール不要
• dropboxに入れておけば、
環境をまたいで使える

• Sass3.2対応も早かった

複数MEで同時作業したい
• 上書き、
コンフリクト対策が必要

• 作業者毎にファイルを分割

• 分割ファイルは
パーシャルで作成する

• ファイル名の最初を
_（アンダーバー）にする

• パーシャルファイルは
インポートして使う

• コンパイル時に
CSSファイルにマージされる

• インポートしてコンパイル

• ファイルを分割すれば、
上書き/コンフリクトが
発生しない

• 手動マージがいらないため
コストもかからない

CSSを直接触りたい
• 関係者全員への
Sassインストールの徹底は
難しい

• CSSディレクトリに、
Sass管理外のCSSを作った

• Sassが使えない環境の人は
このCSSを編集してもらう

• 全員Sassを使える保証が
ない場合
保険として有効

• 放置すると内容がカオスに
• 定期的に内容を
マージする必要あり

• 納品先がCSSを編集する場合

• 修正や追加で戻ってきた時には
Sassが使えない…

• Sassを入れろ、とは言いえない
➡ Sass管理外のCSSで対応できる

修正箇所の見つけ方
• ブラウザかられるのは
CSSまで

• 問題箇所がどのSassファイ
ルにあるかはわからない

line-comments
sass
--watch sass:css
--style expanded
--line-comments

こうなる
:
/* line 301, ../sass/core/_utility.scss */
.fuga {
clear: both;
}

/* line 60, ../sass/style.scss */
.hoge {
color: red;
}
:

• 作業が終わったら元の形式
で再コンパイルすればOK

• 迷ったら--line-comments

:compressedの注意
• 圧縮形式のひとつ
• 改行やコメントを削除し
て、容量を軽減してくれる

• コンパイル後、CSSは1行に
• 複数人での作業時、
CSSがコンフリクト頻発

• diffをとっても
問題箇所がわからない

• 作業時は:expandedなど
他の圧縮形式で

• 内容確定してから
:compressed

コーディングのポイント

色値の扱いのコツ
• 変数に色値を入れると、
カラーネームに
自動変換される

変換例

//変換されない
.hoge{ compiled
color: #000000;
}
CSS
//変換される
.hoge{
$color:#000000; color: #000000;}
.piyo{
color: $color; .piyo {
} color: black;}

• Sass3.2で変換対象の
カラーネームが激増

• カラーネームのほうが
色値より長い場合がある

長くなる例
#fafad2 → lightgoldenrodyellow
#00fa9a → mediumspringgreen
#66cdaa → mediumaquamarine
#7b68ee → mediumslateblue
#48d1cc → mediumturquoise
#c71585 → mediumvioletred
#ffebcd → blanchedalmond
#6495ed → cornflowerblue
#556b2f → darkolivegreen
#778899 → lightslategrey
#b0c4de → lightsteelblue
#3cb371 → mediumseagreen

• 長くなるのはちょっと…
• 色値とカラーネームが
混ざるのも気になる

• 回避策は用意されていない
➡ ので何とかしたい

対応策 : 変換できない色値にする

//カラーネームに存在しないので変換されない
$color:#000001;

.piyo{
color: $color;
}
CSS

.piyo {
compiled
color:#000001;}

• 色が変わってしまう
➡ 厳密な色が必要な場合は使えない

対応策 : 文字列型で管理する

//文字列型にしてから、クォートを外す
$color:unquote('#000000');

.piyo{
color: $color;
}
CSS

.piyo {
compiled
color:#000000;}

対応策 : 文字列型で管理する

//これでも同じ
$color:#{'#000000'};

.piyo{
color: $color;
}
CSS

.piyo {
compiled
color:#000000;}

• 色型が文字列型になる
➡ 色をあつかう関数が使えなくなる

• 出力を:compressedにする
• 色値/カラーネームのうち
最も短い方を
自動的に選択してくれる
➡ 両方の混在は回避できない

• Sassスクリプト自体を修正
• カスタムSass関数で対応
➡ 導入や作業者間の共有で難あり

• 状況によって
対応方法を考えましょう

コードの保守性を上げる
• Mixin、@extend、変数、
Sassコメント
➡ そのコードが何を意図したものかを
明確にできる

こんなCSS
.hoge {
display: inline-block;
*display: inline;
*zoom: 1;
width: 200px;
height: 300px;
overflow: hidden;
padding: 0;
border: none;
background: url(hoge.png) no-repeat 0 0;
text-align: left;
text-indent: -9999px;
*text-indent: 0;
*line-height: 9999px;
*word-wrap: normal;
-webkit-box-shadow: 1px 0 1px #000;
-moz-box-shadow: 1px 0 1px #000;
box-shadow: 1px 0 1px #000;
border: 1px solid #000;
}

Sassではこう

.hoge{
@include img-replacement
(20px,30px,'hoge.png');
@include box-shadow
('1px 0 1px #000');
border:1px solid #000;
}

• 何のためのコードか、
考える必要がない

• 要素固有のルールセットが
見つけやすい
➡ 他人が見てもわかりやすい

• 変数を使うと値そのものに
名前を付けられる

• 何のための値か明示できる

変数を使わないで書く

.hoge{
background-color:#000;
@include linear-gradient
(top, #000, #fff);
}

ちょっとだけ使いやすいソース

.hoge{
$start:#000;
$end :#fff;
background-color:$start;
@include linear-gradient
(top,$start,$end);
}

• 引数に直接値を書くと
値を使いまわしづらい

• コピペもしづらい
• 変数で取り回しがよくなる

• 演算を使う場合も
細かくコメントしておく

• Sassコメントは
CSSに出力されないため、
気軽に書ける

コンパイル後を意識する
• Mixinは@includeされた
箇所で毎回展開される
➡ CSSが醜く肥大化する恐れ

• Mixin以外にも
• 不要なネスト
• @importの重複
➡ 気がつくと肥大化してたりする

• CSSのベタ書きよりも
容量が増えたのでは意味が無い

• コンパイル結果をイメージした
コーディングが重要
➡ たまにはコンパイルしたCSSを
見てみましょう

@extendを安全に使う
• 任意のルールセットに、
グループセレクタとして
追加してくれる

@extendのサンプル

.foo{
" border:1px solid black;
" color:red; compiled
}
:
.hoge{
" @extend .foo; CSS

} .foo,.hoge,.fuga{
.fuga{ " border:1px solid black;
" @extend .foo; " color:red;}
" margin:10px; :
} .fuga{margin:10px;}

• コードのスリム化
• グループセレクタの
管理が容易に

ルールを決めずに使うと…
そのコード修正して大丈夫？
どこかから
@extendされてるかも…

• 運用でカバー
• @extendしたいCSSは
クラス名"extend-"で用意

• その他のルールセットへの
@extendは禁止

NHN Japanでの運用
.extend-box{
" @include linear-gradient(top, #000, #fff);
" @include box-shadow(“0 0 1px #3cf”);
" border:1px solid red;
}
CSS
:
.hoge{ .extend-box,
" @extend .extend-box; .hoge{
" width:100px; " extend-boxのコード}
} :
.hoge{
compiled
width:100px;}

• しかしこんな問題も
• どこからも@extendしなくても、
.extend-のルールセットは
出力されてしまう

• @extendすると、
必ず不要なセレクタが出力される

@extendしなくても出力される
.extend-box{
}
:
CSS
.hoge{
" width:100px; .extend-box{
} " extend-boxのコード}
:
.hoge{
compiled width:100px;}

不要なセレクタが出力される
.extend-box{
}
CSS
:
.hoge{ .extend-box,
" @extend . extend-box; .hoge{
" width:100px; " extend-boxのコード}
} :
.hoge{
compiled
width:100px;}

• Placeholder Selector
(Sass3.2から登場)

• 無駄なセレクタを
抑制できるようになった

Placeholder Selectorのサンプル
%box{
}
: CSS
.hoge{ .hoge{
" @extend %box;
" %boxのコード}
" width:100px;
} :
.hoge{
compiled width:100px;}

• @extend、
正しく使えば怖くない

実践Sass 前編

More Related Content

実践Sass 前編

Editor's Notes

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!