紙ものデザイナーからwebデザイナーになったMariettiです。
社内勉強会でCSS学び直しの機会がありましたので勉強会+αの内容をこちらにまとめようと思います！
CSSの学び直しと言いつつDartSassがメインの内容となっています。
おまけとして最近知ってから多様しているものを紹介します！

Sassとは

Sassとは、CSSの拡張メタ言語の中で現状最もポピュラーなものになります。
メタ言語とはある言語に別のルールを定義するために使われる言語のことで、拡張言語と呼ばれることもあります。
CSSをより効率的に書くことができます。

関数や変数を利用することができ、ヒューマンエラーの防止や効率化が望めます。

Sassのメリット１：ネスト構造で書くことができる

一番の強みはここになるかと思います。
昨今CSSでもネスト構造を使うことはできますが、予期せぬ表示崩れ¹につながることもあります
ネスト構造でCSSを書くことによって、セクションごとにある程度の塊となるので管理が楽になります。
また、管理同様に保守運用の面でもコードが探しやすく扱いやすいです。

Sassのメリット2：変数が利用できる

こちらもかなりの強み。
よく使うカラーやコンテナ幅などを変数にしておくことで、効率的な記述ができるようになります。
サイトの色々な場所に配置されているカラーや数値も、変数の定義元を編集することにより１発で全ての配置先の数値を変更することができます。

Sassのメリット3：ミックスイン（mixin）を利用できる

ミックスインは、定義したCSSのスタイルを別の部分でも使えるようにする機能です。
例えばbtn-1とbtn-2で設定したCSSが複数あり、色意外が全て同一だったとします。
その場合@mixin btnとして同一の設定を書き、@include btnとして出力します。
そうすることで共通のコードの記述量を減らし、効率的なコーディング作業ができます。

Sassのメリット4：ファイル分割して管理しやすくできる

例えばファイルをheader.scss,footer.scss,base.scss,btn.scss...のように分割し、
ディレクトリに分けながら整理することで、管理がとても楽になります！
この方法を使う際は@useを使ってまとめるのが良いかと思います！
詳しくは以前書いた下記記事を参照ください。
https://qiita.com/marietti/items/7f317b88a7255dbfda6e

Sassのメリット5：エラーが表示される

Sassでは、文法を間違えた場合はエラーが出ます。
何がメリットかと思う方も居るかもしれませんが、エラーが出ることによりどこが間違った箇所なのかすぐわかるというところです。
通常のCSSで書いた場合では間違った記述があっても、どこが間違えているかなど自力で探さねばわかりません。ですのでエラーが出るということはとても便利な点なのです。

Sassのコンパイル

Sass（拡張子としては.scss）はそのままhtmlで読み込んでも、ブラウザに認識されません。
なのでコンパイルをしてcssを出力、その出力されたcssをhtmlで読み込む必要があります。
方法はいくつかありますが、簡単にできるものを紹介します。

Live Sass Compilerでコンパイル

Live Sass CompilerというVSCodeの拡張機能を使ってコンパイルを行う方法です。
https://xn--marketplace-zb4j.visualstudio.com/items?itemName=glenn2223.live-sass
使い方としては、

インストールする
VSCodeの画面右下にある、「Watch Sass」というボタンをクリック
ボタンが「Watching...」という状態になったらSass（scss）の監視が行われ、コンパイルが走ります
この状態になることで、リアルタイムで編集したscssの内容がコンパイル先のcssに反映されます。

大まかな流れはこのようになります。
また、cssのコンパイル先などの細かい設定をしたい場合はsetting.jsonに設定を追記します。
必要であれば下記の公式ドキュメントや、調べて記述すればOKです！
https://github.com/ritwickdey/vscode-live-sass-compiler/blob/master/docs/settings.md
この方法が一番とっつきやすく導入が簡単かと個人的には思います！

sassコマンドでコンパイル

お次はターミナルでsassコマンドを使ってコンパイルする方法です。
基本的なコマンドは下記になります！

$ sass hoge foo
（hoge→sassのファイルまでのパス、foo→cssを出力したいファイルパス）

オプションとして頻出しそうなものがこちら

--watch
sassファイルを監視して、自動でコンパイルしてくれる
--no-souse-map
オプションなしだと生成されてしまうソースマップを生成しなくなる
--style compressed
圧縮した状態でコンパイルされる（cssファイルからインデントやコメント、改行などを全て削除し、１行にまとめることができる）

こちらも公式ドキュメントを参照すると詳しくわかります！
https://sass-lang.com/documentation/cli/dart-sass/

GUIが大好きな私は拡張機能でのコンパイルばかりしていますが、
CLIの記事を書いたからにはたまにはsassコマンドも導入したいところ。。
https://qiita.com/marietti/items/ab4cb8835b1b3a733502

分割したファイルを読み込む方法

かつてSassでは分割したファイルの読み込みに@importを使っていましたが、以下の理由は廃止予定で@useを使うことになりました。

Sass使っていた@importが、CSSでもアットルールとして使われるようになった
$で定義した名前が被ってしまうことがある

`@use`でできること

別のscssの読み込み

例えば今書いているscssに、別のscssを読み込んで関数を使用することができます。

hoge

@use "foo" as *;

こう書けば、今書いているhoge.scss内で同ディレクトリ内にあるfoo.scss内のすべての要素を使うことができます。
また、@useで読み込んだファイル（foo.scss）の$fugaで定義されたものは、hoge.$fugaで呼び出すこともできます。

メディアクエリの呼び出し

こうすればメディアクエリも呼び出せます

foo.scss（定義するscss）

//map型(key: value)でブレイクポイントを定義する。
$breakpoints: (
  "sp": "screen and (max-width: 800px)",
  "tb": "screen and (max-width: 900px)",
  "pc": "screen and (min-width: 901px)",
);

@mixin breakPoint($key) {
  @media #{map-get($breakpoints, $key)} {
    @content;
  }
}

hoge.scss（呼び出すscss）

@use 'foo';
  @include var.breakPoint("sp") {
    ...
  }
  @include var.breakPoint("tb") {
    ...
  }
  @include var.breakPoint("pc") {
    ...
  }

このように記述することで、効率的にブレイクポイントの設定をすることができます！

再びの登場となってしまいますが、@useの分割ファイルの読み込みでの使い方はディレクトリ構成を含め以前記事化しましたのでこちらも参照いただけるとありがたいです！
https://qiita.com/marietti/items/7f317b88a7255dbfda6e

`@foward`でできること

@fowardでは、@useでできない2段階でのscssを読み込みができます。
例えば、

base.scss

$theme-color: #ffd700;

foo.scss

@forward "base";

hoge.scss

@use 'foo';
 
.hoge {
  color: foo.$theme-color;
}

このように書くことで、コンパイルし出力されるファイルが以下のようになります

hoge.scss

.hoge {
  color: #ffd700;
}

@forwardは、@useと違い要素を参照するのではなく転送することができます。
@forwardと@useを使い分けて、管理しやすいscssにできるといいなと思います。

CSSの命名規則（BEM）

CSSには、BEM（Block Element Modifier）という命名規則があり、数ある命名規則の中でもかなり厳格なルールです。
巨大化してもサポートしやすく、コードの再利用がしやすいという利点があります。
class名は命名規則に倣って命名しましょう！
公式ドキュメントはこちら
https://en.bem.info/methodology/quick-start/

基本的な記法は下記になります。

.block__element-—modifier

Block（ブロック）

Blockとは、どのページでも使い回すことができるパーツです。
menuやbuttonなど、それが何であるかわかる名前にします。
英単語が2つ以上の場合はハイフンケースで繋げて書きます。

Element（要素）

Elementとは、Blockを構成する要素で、Blockの外では独立して使用できないものです。
Blockの名前を継承して__（アンダースコア2つ）を書いた後にElementの名前をつけます。
CSSを記述する際は詳細度を均一にし、特定のコンテキストに依存しないような記述とします。
例えば、.block .block__elementとclass指定するのではなく、.block__elementとしてレイアウトが変わっても柔軟に対応できるようにします。
またElementは常にBlockの一部であり、独立して存在することはありません。

Modifier（モディファイア）

Modifierとは装飾子という意味で、BlockやElementの見た目、状態、振る舞いを定義するものです。
BlockやElementの名前を継承し、--（ハイフン2つ）を書いた後にModifierの名前をつけます。
大まかに3種類あります。

見た目 - どんなサイズか？どんな色か？　ex.)small,coution
状態 - 他のBlockまたはElementと比べて何が違うか？　ex.)active
振る舞い - それがどのように振る舞う（動作する）か？　ex.)bottom-right

また、Modifierは一つのBlockやElementに対して複数使えます。

この３つの要素に分けて考え、保守管理しやすいCSSを書きたいところですね。
classの指定はどうしても人によってなんとなく個性がでがちなところなのでそちらも少し気をつけていき、常に誰が見てもわかりやすいコードというのを目指していきたいです！
余談ですが、会社での仕事はいつ私が消えても回るようになっていることが理想だと思っているので、どのデータも誰が見ようと編集しやすくなっているということをモットーにデータ作成しています。

おまけ：最近学んだCSSあれこれ

理論上絶対に崩れない角丸

border-radius: calc(1px / 0);

calcを使うことで、理論上絶対に崩れない角丸を実装することができます。
99pxを使うよりはスマートそう？なので私は最近導入しています！
buttonとかで実装するheightの50%角丸に使えます。

メディアクエリ

@media (800px <= width < 1200px)

私が知らなかっただけかもしれませんが、従来のように@media screen and(max-width: 800px)のようにせずとも不等号で表現できるという知見を得てからはこの記法を使っています。
max-widthやmin-widthよりも直感的にわかりやすいかと思います。
MDNの範囲構文というところでも紹介されています！
https://developer.mozilla.org/ja/docs/Learn/CSS/CSS_layout/Media_queries

CSSの優先度

CSSの優先度は、詳細度の点数が設定されておりこの点数が高いほど優先して反映されます。

セレクタの指定	詳細度（点数）	例
ユニバーサルセレクタ	0	*
要素名（タグ）	1	pタグやliタグなど
擬似要素	1	:before,:afterなど
属性セレクタ	10	a[href="hoge"]
classセレクタ	10	.header
IDセレクタ	100	#header
タグのStyle属性で指定	1,000	style="color: #FFF"

どうしてもスタイルが適応されない際に使う!importantですが、これは最終奥義のようなものなのでどうしてもという時以外は使わないようにしましょう...！

おわりに

今回の記事化で、学び直し+αで@useと@forwardの使い方をより詳しく知ることができました！
コーディングしていると、意外と知ったような気持ちになり「ここはこういうものだ、こういう使い方をするものだ」という認識が頭の中で出来上がってしまい、ついいつもと同じように書いてしまうように感じます。
常にアップデートし続けて、ケースに適した書き方をしていきたいです！

実務にて通常のCSSでネスト構造を用いて書いたところ、iPhoneSEやminiなど画面の小さな端末で表示崩れが起きてしまいました。原因が全然わからなくて肝を冷やしました。。 ↩