ラック
Home > ブログ > 記事 > 2015年11月 > Sass(Scss)メモ

Sass(Scss)メモ

カテゴリ: ホームページ, 開発環境

今更ですがSassを使ってみたいと思い立ったので、Sassについて軽く調べたのをまとめ。

まずはSassの特徴など。

  • SassにはSassとScssがある。Sassは{}や;といった記号をなるべく省いてより簡単に書けるようにしている・機能が盛り込んであるなど、独自性が強い。Scssはより本来のcssに近い形で書けるので、cssになじみがある人にはとっつきやすい。今はScssの方が主流。
  • SassもScssもコンパイルしてcssを生成して、それを当て込む形。
  • Sassを使って開発するにはrubyが必要。
  • Sassでできること(一例)
    • Sassではセレクタ(エレメント、ID、クラスなど)やネーム(font-familyなど、ハイフンの前にあるやつ)のネストができる。
    • 変数が使える
    • 四則演算等ができる(pxとinなど別単位も可能)
    • ifやforといったプログラム的な制御ができる
    • 別所で定義を書き(mixin)、引用(include)ができる
    • インポートで複数のcssファイルを1つにまとめられる=cssファイル読み込みのためのHTTPリクエスト回数を減らして負荷を減らせる。場合のよってはモバイルデバイスに優しい設計にできる

 

話は変わって、そもそもSassを何のために導入するか、何を目的とするか、という視点から眺めてみた場合のお話。

「(cssの)クオリティを保つ・メンテナンス性を上昇させる」等を目的とするならば、Sass一直線に限定する必要はなくて、何かしらのきちんとしたルールを定義してあげて、それに則った書き方をすればそれで足りるのでは?という視点。

それに留まらず「いや、Sassがどうしても使いたい!」というならばそれはそれで良いですし、そうでなければ自分に合ったルールやツールを使えば良いのではないか、と考えさせられます。

結局は道具は使いよう、ということで。

 

最後に使用上の注意。Sassを使用すると毎度コンパイルする必要があるためその部分では手間が増えますよ、と。

加えて、CoffeeScriptや画像圧縮など他の「サイトに変更を加えた際に逐一発生する手間」が積み重なった場合、それぞれのツールで一々作業するとなるとむしろ手間が増える、ということになりかねない。

そうであれば、その手間を自動化したい→タスクランナー(予め定義した処理を自動実行するツール)の導入を検討。

その一つにGulpというものがあり、最近はこれが主流の模様?

ただ単純に「最近Sassをよく見るから使ってみたい」というのではなく、より大局的に見る・目的をしっかりと設定して、「作業工数を削減」「アジャイル開発したい」というようなニーズがある場合→SassやCoffeeScriptの導入+合わせてタスクランナーで、コンパイルなどの増えた分の手間を減らすサポート、という感じの運用が目立つようになったのでは、と感じました。

これもCMSの普及やwebアプリケーションの需要の増加(背景にはスマホやタブレットの台頭もあるでしょう)、ビジネスの加速によるDevOps・アジャイル開発等のバックグラウンドや潮流によるところから芽吹いたものなのかなぁ、と思いました。

HTMLコーダがWebプログラムもやるようになり(あるいは逆にWebプログラマがHTMLやcssまで触る)、ある程度は誰でも簡易に書けるように、またタスクランナーによる処理の自動化(誰がやっても同じ処理が走る)によって技術レベル等の差をならしてクオリティを一定に保つ、といった昨今の状況やニーズから普及が進んだのでは…とも。

Sassに限って言えば考え方がプログラム寄りになるので、Webプログラマがcssデザインもやる、というアプローチのときに楽になるかもしれないですね。

逆の場合は、共同作業とかで必要性があるなら別として、あえてSass使う必要はないかもしれないのかなぁ、とも思いましたが実際のところはどうなんでしょうかね。

という半分雑感。

タグ: css, 単語・用語, Sass(Scss), gulp

 



関連する記事一覧