メインコンテンツまでスキップ

Sass

個人の有用 sass 記法についてまとめている(初心者)
吉本式 BEM 設計(BEM 設計ベース)(導入時)

Overview​

Sass（Syntactically Awesome Stylesheets） は、CSS（Cascading Style Sheets）をより効率的かつ管理しやすくするためのプリプロセッサ言語。 Sassを使うことで、通常のCSSにはない機能を利用でき、スタイルシートを簡潔にし、再利用性を高め保守性を向上させることができます。

Sassの実行環境​

実行環境は3つある

Ruby Sass
一番最初に作られたRubyベースののSassの実行環境。
2019年3月に公式のサポートは終了していますが、1年くらい前に「使用率約10%」というアンケート結果を見かけたことがあるので、まだ使用している現場もそれなりにあるかもしれない。

LibSass
まだまだ多くの現場で現役で使われているであろう C/C++ ベースの実行環境。
Node環境でよく使われている node-sass はLibSassをベースに作られているので、LibSassだと意識せずに使っている人もいるかもしれません。

LibSass非推奨問題 もともと @importが段階的に廃止となるという話もあり、公式としてはLibSassではなく Dart Sass を使うことを推奨している、ということは数年前から言われていました。そういった中で、2020年10月に唐突にLibSassが非推奨となりました。

Dart Sass Dart 言語で書かれた最新の実行環境。現在の公式推奨環境で、今後廃止予定の @import の代替となる @use や @forwordが唯一使える環境です。

  • version確認 $ sass -v

  • コメント、文字コード Sassでは css /* */ が使えるがJSなどで使用する js // のような1行コメントも使用ができる ※CSSのコメントはコンパイルされても削除され図に残る。

  • 文字コードの指定 コメントなどに日本語を含める場合、ファイルの先頭で@charsetを使用して UTF-8 を設定する必要がある。

親セレクターの参照 (&)​

セレクターに&を使うとネストしている親セレクターを参照できる。

変数 (Variables: $)​

Sassの変数では以下のような決まりがある。
変数の宣言は $ から初める必要がある。
半角数字から始まる名前や連続したハイフンから始まる名前はエラーになる。

使用方法として
基本のフォントカラーやリンクカラー、ベースフォントなどをあらかじめ指定しておくと便利

Sass でのアンダースコアとハイフンは互換性がある​

例として $main-width と変数を定義すると、その変数を $main_width で参照できてしまう。
どちらかに統一した方が管理がしやすいかもしれない。

変数のスコープ​

トップレベルの位置で定義した変数はどこでも有効になるが、ブラケット内で定義をした変数はブラケット内のみで有効になる。

Sass のデータタイプ型​

Sassには型（データタイプ）が存在し、現在7種類に分類されている。

演算(Operations)​

Sassでは四則演算や文字列の連結、色の演算等を行うことができる

Sassのモジュールシステム​

参考URL

import があるがそれは使わないこと

SCSS（Sass）のファイルにおけるアンダースコア（_）の役割について説明します。

partial file​

Sassでファイルを分割管理する方法と3つのメリット【@import, パーシャル】

アンダースコアで始まるファイルは、パーシャルファイル（partial file）と呼ばれます。パーシャルファイルは、CSSを出力しない、SCSSのコード断片をまとめたファイル。
これらは、他のSCSSファイルにインポートされることを前提として作成されている。
また最終的には1つのCSSファイルにまとめることができる。

メリット​

  • 作業ファイルをいくつにも分割できる
  • 最終的に1つのCSSファイルにまとめることができる
    • 読み込み速度の向上（HTTPリクエストが減るため）

現代のHTTPリクエスト​

HTTP/2の利点:

HTTP/2では、複数のリクエストを並列に処理できる。
これにより、複数のCSSファイルやその他のリソースを同時に読み込む際のオーバーヘッドが大幅に減少します。

パフォーマンスの最適化: 複数の小さなファイルをひとつにまとめる（バンドルする）ことは、古いHTTP/1.1ではパフォーマンス向上に効果的でした。しかし、HTTP/2の導入により、必ずしもひとつにまとめる必要はなくなりました。 結論 HTTP/2の導入により、複数の小さなファイルを1つにまとめる必要性は低くなったものの、パーシャルファイルを利用してコードをモジュール化し、管理しやすくする利点は依然として有効です。パーシャルファイルを使うことで、開発効率やコードのメンテナンス性が向上し、プロジェクト全体の品質を保つことができます。HTTP/2の特性を活かしつつ、適切な構造化を心がけるのが最適です。

パーシャルファイルの利点​

  1. モジュール化：コードを整理して、再利用可能なモジュールとして管理できます。
  2. メンテナンス性向上：小さなファイルに分割することで、変更や追加がしやすくなります。
  3. 読み込み時の効率化：必要なパーシャルのみをインポートして使用できるため、ムダなコードを読み込む必要がありません。

パーシャルファイルはインポートされることで機能し、メインのスタイルシートに統合されます。

ファイルの分割(partial)​

Sassは分割したSassファイルをひとつのCSSファイルとしてまとめることが可能。
インポートしたSassファイルはコンパイルするとCSSファイルとして生成されるが、CSSファイルとして生成したくない場合は、ファイル名の先頭に _(アンダースコア) をつけることで、コンパイルしてもCSSファイルを生成しないようにすることができる

Sass ファイル名の先頭にアンダースコアを付けると、コンパイルしても CSS ファイルが生成されないという仕様があり、この部分的な Sass ファイルまたは機能をパーシャル（partial）と呼びます。 これにより「Sass ではファイルを分割して管理するが、コンパイル後に生成される CSS ファイルは１つだけ」ということが可能になります。 partial は、CSS ファイルには変換されないため、最終的に CSS ファイルとして変換したいメインの Sass ファイルから読み込むようにします。

パーシャル(partial)のインポート​

できるパーシャルを読み込む（インポートする）場合は、拡張子とアンダーバーを省略できる（拡張子やアンダーバーをつけたままでも問題はない）

パーシェルを使ったディレクトリ構成/ファイル構成​

project
|\_css/
| |- style.css（生成される CSS）
|
 |\_sass/
|- \_reset.scss（リセット用）
|- \_extend.scss（@extend の定義）
|- \_mixin.scss（@mixin の定義）
|- \_settings.scss（変数などの設定の定義）
|- style.scss（メインのスタイルと各 Sass ファイルのインポート用）

ミックスイン @mixin​

ミックスインを使うとプロパティやセレクタをまとめてワンセットにしておいて、それらを読み込むことができます。 ミックスインは @mixin ディレクティブを用いて定義し、@include ディレクティブで定義したミックスインを呼び出します。 ミックスインは、@include で挿入した箇所で展開されるコード片で、ミックスイン自体のコードは CSS としてコンパイルされず、@include されてはじめて実体を持ちます。 そのため、よく使うものを一通りライブラリとして読み込んでおいて必要に応じて呼び出す、という使い方が可能です。 ミックスインもスコープを持つので、ルールセット内で定義するとその中でしか利用できません。 またミックスインでは引数を取ることができるので、より使い回しが柔軟にできます。

@mixin と @extend と @fucntion のコンパイル違い​

参考URL

  • extend
.hoge1 {
    margin:10px 0;
    padding:5px;
}
.hoge2{
  @extend .hoge1;
  padding:0;
}

↓にコンパイルされる

.hoge1, .hoge2 {
  margin: 10px 0;
  padding: 5px;
}
.hoge2 {
  padding: 0;
}

@extendで呼ばれたhoge1の中身がごそっとhoge2にも反映されています。 これだけを見ると、1か所で書けるものを2か所にわけて書くのは非効率！と思うかもしれないですが、1つのクラス内で複数回@extendすることもできますし、@extendしているクラスを@extendすることもできますので、使い方次第で絶大な効果を発揮してくれます。

  • mixin mixinは、extendとの大きな違いは2つあると思います。細かくはいっぱいあるのですが。 extendと違いグルーピングされない extendの例と同じ内容をmixinで書くと一目瞭然です。
@mixin hoge {
    margin:10px 0;
    padding:5px;
}
.hoge1{
  @include hoge;
}
.hoge2{
  @include hoge;
  padding:0;
}

↓にコンパイルされる

.hoge1 {
  margin: 10px 0;
  padding: 5px;
}
.hoge2 {
  margin: 10px 0;
  padding: 5px;
  padding: 0;
}

となります。 extendで書き出されたCSSと内容は同じなのですが、「.hoge1, .hoge2 」のようにグルーピングされません。
この違いだけですと、extendのほうがソースも短くなるのでいいかと思いますが、制作会社がベースをSassで作って、日々の更新はクライアント企業の担当者がCSSファイルを触るサイトなどでは分けて書き出したほうが良い場合もあるかもしれません。

extendと違い引数（パラメーター）を渡すことができる こちらがミックスインを使う最大の理由になるかと思います。説明するよりも例を見たほうが早いと思いますので、早速書いてみます。

  • function

functionは引数などの扱いはmixinと一緒ですが、返すものが値となります。
簡単な例ですがファイル名を引数で渡してurlをセットするfunctionは下記になります。

$hoge:'img/';
$png:'.png';
@function urlPng($fileName) {
  @return url($hoge+$fileName+$png);
}
.hoge1 {
  background:urlPng('test');
}
.hoge2 {
  background:url($hoge+'test'+$png);
}

↓にコンパイルされる

.hoge1 {
  background: url("img/test.png");
}
.hoge2 {
  background: url("img/test.png");
}

と「.hoge1」も「.hoge2」も同じになります。「.hoge2」のように直接四則演算を行ったりしてもいいのですが、functionを作ってあげたほうが美しいですね。

に最終更新