読者です 読者をやめる 読者になる 読者になる

vol.61 CSS肥大化を抑える Sassを使ったコード設計の実践

f:id:BOEL:20170428124700j:plain

こんにちは、Webエンジニアの佐藤です。


前回は CSS肥大化を抑える 破綻しないコード設計とSassの導入についてご紹介しました。


今回は、私が業務で使っているCoda2でのSassのインストールコンパイル方法と、
また前回を踏まえて、実際に業務での実践で意識した点やその結果、改善ポイントなどをあげていきます。

 

Sassのインストール方法
Codaでの使い方、コンパイルについて


CodaへのSassのインストール方法

Codaの公式サイトへアクセスします。


Coda公式サイト
メニューの[ Plug-ins ]を選び、検索フォームから「Sass」を検索すると
Coda用のSassのプラグインが表示されます。


黄緑色の[ Install ]をクリックすることでCodaが立ち上がり、
Sassが自動でCodaにインストールされます。
Coda「環境設定」のプラグインタブ内の一般の欄に「Sass」が追加されていれば
インストールの完了です。


CodaでSass(scss)をコンパイル

拡張子が「.scss」のscssファイルを作成し、
css、scssの記述方法に合わせてコードを書いて保存をします。
Codaでは、scssファイルを保存すると、同階層に同じファイル名のCSSファイルが自動で吐き出されます。


scssでコードを書いて、上書き保存をするたびにcssファイルを更新していってくれるので
コンパイルをするたびにコマンド実行などの手間がなく便利です。


今回実践したポイント

・scssファイルをページごとに分け、importでひとつのcssにまとめる


・クラスの共通化


・mixin、extendの使用


・入れ子(ネスティング)をしすぎないこと

 

実践した結果


よかったこと

・ページごとに分けているので見やすい、それぞれのファイルのコード量が少なく軽い


1ページごとにscssファイルを分けたため修正の際などに作業するファイルが明確になった。


1ページのscssファイルをさらにPC用とレスポンシブ用の2ファイルに分けたため、
それぞれのファイルサイズが格段に小さくなり、作業効率が良くなった。


・同じコードが減り、無駄な記述がなくなった


共通のクラスを使用、またmixinやextendを使用するなど
同じコードを何度も繰り返し書かず済んだことですっきりしたコードになった。

 

・多量なインデント、深すぎる階層のセレクタがなくなった


scss内で入れ子をしすぎ、エディタ画面の半分がインデントで埋まるということや
必要以上に深い階層の、強いセレクタがなくなった。


よくなかったこと

・importでファイルを細かく分けたためコードが見つからないことがある


ページごとにファイルを分けたため、一部で使っていたコードを後から共通化したあと
その記述を特定ページのscssファイルにそのまま残してしまうなど、
編集したい記述を探すのに手間取ってしまった。


・extend継承のしすぎ


ボタンなどの記述にextendを使用したが、共通化するセレクタの数が増えすぎてしまい
コンパイル後、大量のセレクタが羅列してしまった。


またextendを使用したセレクタを入れ子にして別の場所で使った場合、
そちらでもグループ化されて、いらない上書きが発生してしまった。


//extend)

.btn1{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{@extend .btn1; border:1px dotted #cccccc;}
.box{
.btn1{border-color:#ff0000;}
}

 


//extendコンパイル後)

.btn1,.btn2{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{border:1px dotted #cccccc;}
.box .btn1,.box .btn2{border-color:#ff0000;}

 

改善するには

・共通の記述はもとより共通用scssに書いておく
これはもちろん大前提の話ではありますが、製作中のレイアウト変更はつきものです。


あとからコードを共通化する必要がでてきたなら、すぐに共通用のscssに移動させること、
また、記述位置の問題などですぐに記述の移動ができない場合は
検索してすぐ見つけられるようコメントアウトを残すなどの対策をしましょう。


・同じextendの記述を使いすぎない


extendはmixinと違い、同じコードにセレクタがグループ化されます。


自動でグループ化され、同じ記述が増えないので簡単かつ便利ですが
extendを使用する分だけセレクタの羅列が膨大になっていきます。


それを防ぐためには使用回数を数回に決めておくか、共通のクラスをひとつ作っておくべきでしょう。


プレースホルダセレクタを使ったグループ化


extendにはプレースホルダセレクタが専用で設けられています。
プレースホルダセレクタは「#」や「.」ではなく「%」で定義し、
通常のセレクタとは違ってmixinのような扱いになり、呼び出さないと使えず、コンパイルもされない要素です。


これなら別の記述から予期しないグループ化がなくなり、必要な記述を呼び出して使うことができます。


//プレースホルダセレクタを使ったextend)

%btn-extend{border:1px solid #000000; width:120px; font-size:14px;}

.btn1{@extend %btn-extend;}
.btn2{@extend %btn-extend; border:1px dotted #cccccc;}
.box{
.btn1{border-color:#ff0000;}
}

 


//プレースホルダセレクタを使ったextendコンパイル後)

.btn1,.btn2{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{border:1px dotted #cccccc;}
.box .btn1{border-color:#ff0000;}


今回実践してみて


前回の記事でまとめたポイントや注意点を意識し、今回業務で実践してみた結果として、 最終的に吐き出されたCSSは今までより容量を抑えることができたのではないかと感じます。
今回はCSSのサイズを抑えることを意識してのコード設計だったため、リファクタリングなどと違い、比較対象がないので憶測ではありますが、Sassの活用・記述の共通化などで大きく変わった部分が多いと思いました。
しかし、今回の実践では改善するべき箇所がいくつも見つかり、
CSSを最小限に抑えるための効率的なワークフローにはまだまだ至らないこともわかりました。
この記事で紹介しきれていない、まだ使ったことのないSassの機能などもあるので、
それらも駆使し、CSSの容量を抑え、よりよいコード設計を目標に精進していきたいと思います。