Sassは必要？メリットは？ Sassからの卒業。Back to CSS。
です・ます調の文章でなくてすみません。当初は個人的なメモ書きだったためです。
Contents - 目次
Sassで書く意味はなんだろう？
Sassのメリット。
まず第一に、Sassを使用する理由・メリットは何だっただろう？
個人的には、、、
- 変数を使える。
- 関数を使える。
- 四則演算が使える。
- Sassのかっこよさげなイメージ。
この4つは大きかった。テキストや背景色などのカラーコードを変数に格納、widthの幅を四則演算、というのは非常に便利だった。そして何より4つ目の、SassのロゴやAwesomeなイメージがよかった。
mixinも最初は、便利そうじゃないか！と思った。これからはSassの時代だろう！とも感じた。
Sassのデメリット。
- コンパイルが必須。
- .scssファイルもしくは.sassファイルが必要。
- 多すぎるオリジナルルール。
- 大手サイトがSassを非推奨に。
そんなSassだが、早々に使うのをやめた。使ってすぐに気がついたのは、コンパイルの手間とそれに伴うファイル数の増大だった。Sass独自のルールや種類も多く、ひとつひとつの作業がいちいちと面倒すぎる。その時点で使うのをやめた。卒Sassだ。
CSSへのプログラミング導入のきっかけとしての影響力は確かにすごかった。
Sassのその他の特徴。
オリジナルルールとその結果。
- ネスト、ネスティング。
- パーツを分割できる。
- 結果的にCSSとなる。
などがある。他にも色々とあるが、この３つはSass利用者であればほぼ必ず経験することだ。
この３つの特徴の中で（他に多々あるが）最も疑問となるのが、結果的にCSSになる、というところだ。
さらに生の.cssファイルと違い、サーバー上で直接編集できない.scssファイルは修正が不便だった。
特に新しいデバイスが普及し、レスポンシブ対応のためにスマホやタブレットの実機でのブラウザ確認をする上で、テストサーバーや本サーバーで編集できないというのは作業上での大きなストレスとなった。
Sassはサーバー上で管理しづらい。
ローカル環境も必要だが、テストサーバー、デモサーバーはより重要。
ちなみに以前そのことを指摘すると、ChromeとIPアドレスでローカル環境を構築すればPCでもスマホ実機でも確認できると、ある学校で生徒さんへ教えている「Sassが大好きな先生」と出会って疑問に思ったことがある。
その「先生」はよくある卒業生から講師になったパターンであり、制作会社での実務経験はなく、おそらく実案件でのサイト制作経験もない人物だった。生徒さんをお客様と呼んだ数時間後に今度はクソ呼ばわりするというタイプで、影でのパワハラも日常的だった。
ローカル環境よりもサーバーで確認する方が良いだろう。
ちなみにたとえChromeでローカル環境を作ったとしても、国内シェア率が高いiPhoneのSafariが確認できないという致命的な問題をカバーできない。
Chromeだけの確認であれば、デベロッパーツールでのエミュレータでほぼほぼ十分であり、逆にテストサーバー、デモサーバーを立ち上げないWeb制作会社なんてほとんど聞いたことがない。
そのような制限の多いローカル環境を構築するよりも、サーバーを用意しアップした方がずっと速く確実だ。
CSS3の登場と普及。
そこで改めて思った。最初からCSSで書いた方がいいんじゃないか？と。ちょうどW3CからリリースされたCSS3が普及し始める時期でもあった。
CSSはすでに進化している。
CSS3によるプログラミング。
CSSの生みの親であるHåkon Wium Lie（ホーコン・ウィウム・リー）氏によれば、もともとCSSはプログラミング言語にならないように取り組んでいたそうだ。
参照：Håkon Wium Lie（ホーコン・ウィウム・リー）氏によるツイッター。
だが、時代は変わり、現在のCSSのバージョン（レベル）では、変数も四則演算もCSS単体でできる。
変数と四則演算。
例）
/* 変数を宣言し、格納する。 */
:root {
--white: rgb(255, 255, 255) /*#fff*/;
--black: rgb(0, 0, 0) /*#000*/;
--sans_serif: "ヒラギノ角ゴ Pro", "Hiragino Kaku Gothic Pro", sans-serif;
--sans_serif_02: 游ゴシック, 游ゴシック体, 'Yu Gothic', YuGothic, sans-serif;
--serif: 游明朝, 游明朝体, 'Yu Mincho', YuMincho, serif;
}
/* var()で変数を呼び出す。 */
body {
background-color: ver(--white);
color: var(--black);
font-family: var(--sans_serif);
}
/* divの幅をcalc()関数で計算する。 */
div {
width: calc(100% / 3);
}
ネスト、ネスティング。
2021年8月には、W3CからSassのようなネスティングの書き方がCSSベースでできるような草案も出ている。これももしかすると、Sassの功績なのかもしれない。
イメージとしてCSSはSassに比べて古っぽさがあるのかもしれないが、それは錯覚で、そもそもSassの最終形態はCSSだ。
事実として.scssファイル、.sassファイルはコンパイル後に.cssファイルとなる。
標準語か？ 方言か？
GoogleやApple、Microsoft、WordPressは、HTMLやCSSへの対応はしているが、Sassの対応はしてはいない。GoogleやApple、Microsoftが作ったブラウザは、生で書かれた.scssファイルを読み込んだりしないし、WordPressもそうだ。
Sassというのはあくまでもローカルな言語であり、世界基準の言語、Web標準言語ではないのだ。
頑張って勉強しても、テストにSassは出ない。
ちょっと冷静に考えてみてほしい。
検定試験ではHTMLやCSSはごく当然に出題されるが、Sassの検定試験が不要とされている現状はなぜだろうか？
現時点では一部のコーダー間だけで通じる言語であり、残念ながらブラウザやユーザーやGoogleのbotにSassは通じない。
Sassのイメージ、いわゆるイケてる感じのイメージは、コーダーの間だけでの流行であり、実社会ではまずほとんど誰も知らない。
Sassを使わない制作会社はあるが、CSSを使わない制作会社はない。
これも見落とされている。Sassを使用していない制作会社は普通にある。そもそも制作会社でバリバリとコーディングをしている人たちはSNSなどで情報発信する時間を取りにくいので、その事実を知られていないのではないだろうか。
クライアントやユーザーに求められるのはWebサイトの見た目や機能であり、そこに直接関与しないSassよりもUI、UXを高めるCSS3でのアニメーションの方が優先される。そういう現場の実情が伝わっていないのかもしれない。
ノーコード。
近年多い、「ノーコード」についても同様だ。コードを書かなくても良いのなら、デザイナーとしては逆にその方が楽だ。歓迎されるだろう。だが、実務の現場はそうはなっていない。
本当にノーコードで済むのなら、世の中のサイトはWordPressのフリーテーマやWix、STUDIOなどありふれるだろう。でも未だそうなってはいないのは、どうしてだろうか？
Flashと、HTML5&CSS3。
以前、Flashというとても便利なオーサリングソフト、その結果としてのアニメーション、そしてプラットフォームがあった。全盛時にはフラッシャーと呼ばれるFlash専門の人たちもおり、サイト全体はもちろん、バナーなどにも良く使われていた。
Flashはとてもよくできていて、マウスやキーボードで感覚的に、GUIによって作ることができ、かつアニメーションができる。デザイナーには非常に使い勝手がよかった。コードはほとんど書く必要がなかった。
プラットフォームの問題。
また、Flash自体がプラットフォームとなるので、デバイスがMacでもWinでも、ブラウザがInternet ExplorerでもChromeでもSafariでもFirefoxでも、ユーザー側がFlash Playerをインストールすればそれだけでよかった。
Flashの普及率は高かった。
それはそれほど面倒なことではなく、普通に受け入れられていて、90%以上とも95%以上とも言われる普及率があった。なので、いわゆる「ブラウザ対応」がほとんど必要なかった。
数年前までネット上に普通に存在しており、WordPressのプラグインにもよくあった。
それがどうだろう。2021年現在、Flashで作られたサイトは全く見当たらない。
全盛期からわずか10年程だ。
Flashは消えてしまった。Sassはどうだろう？
- AppleやGoogleが対応をしなかった。
- Flashではなく、HTML5が採用された。
- そしてiPhoneやAndroidのスマホは普及した。
SassはFlash同様、ブラウザやデバイス、サーチエンジンを作っているプラットフォーム企業が対応していない。
これが全てではないが、このような場合、わざわざ使う必要性はどこにあるのだろう。
ユーザーがサイトを見ている時に「お、これはSassだな！」なんて思うだろうか？
WebサイトはHTMLでできている。
世界中にあるWebサイトはほとんどはHTMLでできている。個人的にはHTML以外でできているサイトは見たことがない。
かつてのFlashもまずHTMLがあって、Flashプレイヤーがあって、その中でActionScriptという言語で動いていた。
WordPressのファイルはPHPでできているが、そのPHPも結果的にはHTMLの中で働いている。JavaScriptもそうだ。
当たり前なのだ。WebサイトはHTMLによってできているのだから。
W3Cは、Sassの勧告はしていない。WHATWGもしていない。
世界最初のWebサイトはTim Berners-Lee（ティム・バーナーズ＝リー）氏によってHTMLで書かれた。WWWの生みの親だ。彼はW3Cという団体を立ち上げ、そのW3CがHTML5やCSS3を作って世に出している。
普段何気なく見ているサイトを右クリックしてソースを表示させてみると、１行目に「<!DOCTYPE html>」と書かれているはずだ。その意味は、シンプルに、「HTMLの文書です」、という意味だ。
Web標準か？ ひとときの流行か？
HTMLやCSSが国の憲法のようなものだとすると、Sassは地方自治体で流行っているルールみたいなものなのだ。
2021年現在ではW3Cとダブルスタンダード的な立ち位置だったWHATWGによる「HTML Living Standard」がWeb標準となっているようだが、ベースはHTML5であり、コーディング作業においては両者に大きな違いはない。
現にWHATWGのサイトのHTML文法チェッカーは、W3Cのものがそのままリンクされている。そこにSassはいない。
初期のWebサイト。
Webサイトというよりも、Webページといった感じである。DOCTYPE宣言やhtmlタグはないが、HTML（HyperText Markup Language)の基のテキストとリンクである。
- 世界最初のWebサイト：The World Wide Web project
- 世界最初のWebサイト（W3Cの復刻ページ）：The World Wide Web project
- 日本最初のWebサイト：KEK Entry Point
出典：Wikipedia
また、1990年代のインターネット黎明期に作られたサイトが、2020年代でも普通に運営されているという例もある。
SassどころかCSSも使われていない。
ホームページビルダーというオーサーリングツール、いわゆるノーコードのツールで作成されている。
レトロ感やあまりの高速表示が人気となり、リニューアルの気配もない。
- 俳優の阿部寛さんのWebサイト：阿部 寛のホームページ
プラットフォーマーがSass対応をしていない。
AppleやGoogle、Microsoftは、Sassを読み込まない。
- AppleやGoogle、Microsoftが採用をしていない。
- Sassではなく、CSS3が適用されている。
- そしてiPhoneやAndroidのスマホは普及した。
デバイスやブラウザ、サーチエンジンを作っているプラットフォーム企業が対応していない。
これが全てではないが、このような場合、わざわざ使う必要性はどこにあるのだろう。
Flashの時と似たような状況ではないだろうか？
ShopifyのテーマではSassはむしろ非推奨に。
推奨されないものは使いづらく、人にも勧めづらい。
ちなみに大手オンラインストア「Shopify」では、すでにSassは非推奨となっている。Sassのマイナス面として、Sassはスピードが遅いということがあげられている。
Back to CSS
Sassはプログラムの機能がある言語だが、その結果的な役割はCSSのファイルを作成することだ。もともとCSSはデザイン用の言語であり、プログラミング用の言語ではなかった。しかしバージョンアップ（レベルアップ）を重ね、現在ではプログラムの要素も取り入れられ、変数や四則演算が普通にできる。
jQueryとの違い。
CSSとSassの関係は、JavaScriptとjQueryの関係に似ているとも言える。jQueryはFlashの代替にもなっており、ユーザーエクスペリエンスに直結しやすい。
ただし、大きな違いがある。jQueryの最終形態は普通のブラウザで動くJavaScriptでなので、環境構築が必要ない。ローカルでもサーバーでも、そのままブラウザ上だけで完結する。
何もインストールする必要がなく、特にファイル数も増えない。
セレクタやメソッドの使いやすさも、プレーンなJavaScriptよりも圧倒的だ。
「box」というセレクタを取得・指定したい場合、JavaScriptでは「document.getElementsByClassName(‘box’)」となるが、jQueryなら「$(‘.box’)」で済む。
なので、「手軽」なのだ。
モジュール？ パーツ？
普通のWeb制作の際に、「モジュール」という言葉を聞くことが時々ある。この言葉もある意味魔法だ。
モジュールというのは「パーツ」と同意語だが、HTMLやCSSではモジュールという言葉はあまり使わない。全く使っていないというわけではないが、わざわざ使う必要もない。
WordPressでもほぼ使わず、もちろん日常生活でも使わない。プログラミングの分野でよく用いられる、いわゆる「専門用語」、「業界用語」だ。
CSS設計？
「CSS設計」も同様に使われている。これらの言葉は、使っているだけでその気になれてしまうのかもしれない。
そもそもWebサイトは「HTML」という「Document Type」であり、前述の通り、「文章」だ。サイトを設計するのは「Hyper Text Markup Language（HTML）」である。
CSSはサイトを見やすくするための装飾やレイアウトなどの補助的な役割であり、Google botは基本的にHTMLをクロールしている。
ChatGPTやBard、Bingもそうだろう。
WordPressではパーツ。
WordPressのテンプレートタグでは比較的一般的な言葉である「パート（part）」が使用されており、XOOPSでは専門的な「モジュール（module）」が使われていた。CSSの草案でもモジュールという言葉は使われてはいる。
少なくともHTMLやCSS、WordPressでのサイト構築の際は、日常生活と同様に普通に「パーツ」で通じる。そのパーツの分割やネスティングレベルの構築はそもそもCSS単位で十分可能なのだ。いちいちと専門用語を使う必要はなく、むしろ違和感を感じる。
マウントを取りがたる人が使うイメージもある。
管理はHTMLとCSSで可能かつ無難。
Sassは管理がしやすいとも言われているが、それは使用する日常言語やHTML、CSSを管理できてから言うべき言葉だろう。
Sassにハマり、HTMLのマークアップがおろそかになってはいないだろうか？
Flashのように無くなってしまったり、Shopifyのように非推奨になったらどうするのだろう？
Sassでできることは、CSSでカバーできる。
例外として、デザインもSEOもやらず、コーダー専門、プログラム専門の場合は別かもしれない。そういう局面では、Sassは便利なのだろうと思う。
ただし、2022年には、@importが廃止され、@useへ移行しなければならない。。。
…ここまで来るともう、普通にスタンダードなCSSで書いた方が自然じゃないだろうか。
Sassでできることは、今はもうCSSでカバーできる。
関連：
SassとBEM。やりすぎなSassやBEMたちと、やりすぎたclassセレクタ。
以上、参考になれば幸いです。
※Webデザインは実務数年、職業訓練校講師数年、フリーランス数年、計15年以上のキャリアがありますが、一気にがぁっと書いています。（元々はメモ書きでしたので順次見直し、更新しています。） ※事実や経験、調査や検証を基にしていますが、万一なにかしら不備・不足などがありましたらすみません。お知らせいただければ訂正いたします。 ※写真は主にUnsplashやPixabayのフリー素材を利用させていただいております。その他の写真や動画もフリー素材やパブリックドメイン、購入素材、もしくは自前のものを使用しております。
