Contents - 目次
Sassで書く意味はなんだろう？
Sassのメリット。
まず第一に、Sassを使用する理由・メリットは何だっただろう？
個人的には…
- 変数を使える。
- 関数を使える。
- 四則演算が使える。
- Sassのかっこよさげなイメージ。
この4つは大きかった。テキストや背景色などのカラーコードを変数に格納、widthの幅を四則演算、というのは非常に便利だった。そして何より4つ目の、SassのロゴやAwesomeなイメージがよかった。
mixinも最初は、便利そうじゃないか！と思った。これからはSassの時代だろう！とも感じた。
Sassのデメリット。
- コンパイルが必須。
- .scssファイルもしくは.sassファイルが必要。
- 多すぎるオリジナルルール。
- 大手サイトがSassを非推奨に。
そんなSassだが、早々に使うのをやめた。使ってすぐに気がついたのは、コンパイルの手間とそれに伴うファイル数の増大だった。
Sass独自のルールや種類も多く、ひとつひとつの作業がいちいちと面倒すぎる。その時点で使うのをやめた。卒Sassだ。
CSSへのプログラミング機能導入のきっかけとしてのSassの影響力は、確かにすごかった。
Sassのその他の特徴。
オリジナルルールとその結果。
- ネスト（ネスティング）。
- パーツに分割できる。
- 結果的にCSSとなる。
他にも色々とあるが、この３つはSass利用者であればほぼ必ず経験すること。
この３つの特徴の中で（他に多々あるが）最も疑問となるのが、結果的にCSSになる、というところ。
さらに生の.cssファイルと違い、サーバー上で直接編集できない.scssファイルは修正が不便だった。
特に新しいデバイスが普及し、レスポンシブ対応のためにスマホやタブレットの実機でのブラウザ確認をする上で、テストサーバーや本サーバーで編集できないというのは作業上での大きなストレスとなった。
Sassはサーバー上で管理しづらい。
ローカル環境も必要だが、テストサーバー、デモサーバーはより重要。
以前そのことを指摘すると、ChromeとIPアドレスでローカル環境を構築すればPCでもスマホ実機でも確認できると、ある学校で生徒さんへ教えている「Sassが大好きな先生」と出会って疑問に思ったことがある。
その「先生」はよくある卒業生から講師になったパターンであり、制作会社での実務経験はなく、おそらく個人でも実案件のサイト制作をしたことがない人物だった。
生徒さんをお客様と呼んだ数時間後に今度はクソ呼ばわりするというタイプで、影でのパワハラも日常的だった。
ローカル環境よりもサーバー環境で確認する方が良いだろう。
ちなみにたとえChromeでローカル環境を作ったとしても、国内シェア率が高いiPhoneのSafariが確認できないという致命的な問題をカバーできない。
Chromeだけの確認であれば、デベロッパーツールでのエミュレータでほぼほぼ十分であり、逆にテストサーバー、デモサーバーを立ち上げないWeb制作会社なんてまず聞いたことがない。
そのような制限の多いローカル環境を構築するよりも、サーバーを用意しアップした方がずっと速く確実で、実務でも普通はそうなっている。
HTML5とCSS3。
CSS3の登場と普及。
そこで改めて思った。最初からCSSで書いた方がいいんじゃないか？と。ちょうどW3CからリリースされたCSS3が普及し始める時期でもあった。
CSSはすでに進化している。
CSS3によるプログラミング。
CSSの生みの親であるHåkon Wium Lie（ホーコン・ウィウム・リー）氏によれば、もともとCSSはプログラミング言語にならないように取り組んでいたという。
参照：Håkon Wium Lie（ホーコン・ウィウム・リー）氏によるツイッター。
だが、時代は変わり、現在のCSSのバージョン（レベル）では、変数も四則演算も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からネスティングの書き方がCSSベースでできるような草案も出ている。実例が記載されているので、Sassの影響があることがわかる。
イメージとしてCSSはSassに比べて古っぽさがあるのかもしれないが、それは錯覚で、そもそもSassの最終形態はCSSであり、CSSは進化している。
事実として.scssファイル、.sassファイルはコンパイル後に.cssファイルとなる。
標準語か？ 方言か？
GoogleやApple、Microsoft、WordPressは、HTMLやCSSへの対応はしているが、Sassの対応はしてはいない。GoogleやApple、Microsoftが作ったブラウザは、生で書かれた.scssファイルを読み込んだりしないし、WordPressもそう。
Sassというのはあくまでもローカルな言語であり、世界基準の言語、Web標準言語ではない。
頑張って勉強しても、テストにSassは出ない。
ちょっと冷静に考えてみてほしい。
Web系の検定試験ではHTMLやCSSはごく当然に出題されるが、Sassの検定試験が見当たらない現状はなぜだろうか？
現時点ではSassは一部のコーダー間だけで通じる言語であり、残念ながらブラウザやユーザーやGoogleのbotには通じない。
Sassのイメージ、いわゆるイケてる感じのイメージは、コーダーの間だけでの流行であり、実社会ではまずほとんど誰も知らない。
Sassを使わない制作会社はあるが、CSSを使わない制作会社はない。
これも見落とされている。Sassを使用していない制作会社は普通にある。
そもそも制作会社でバリバリとコーディングをしている人たちはSNSなどで情報発信する時間を取りにくいので、その事実を知られていないのではないだろうか。
クライアントやユーザーに求められるのはWebサイトの見た目や機能であり、そこに直接関与しないSassよりもUI、UXを高めるCSS3の方が優先される。
そういう現場の実情が伝わっていないのかもしれない。
ノーコード。
近年多い、「ノーコード」についても同様だ。コードを書かなくても良いのなら、デザイナーとしては逆にその方が楽だ。歓迎されるだろう。だが、実務の現場はそうはなっていない。
本当にノーコードで済むのなら、世の中のサイトはWixやSTUDIOなどでありふれるだろう。でも未だそうなってはいないのは、どうしてだろうか？
Flashと、HTML5&CSS3。
Flashとプラットフォーム。
Flashの衰退。
以前、Flashというとても便利なオーサリングソフト、その結果としてのアニメーション、そしてプラットフォームがあった。全盛時にはフラッシャーと呼ばれるFlash専門の人たちもおり、サイト全体はもちろん、バナーなどにも良く使われていた。
Flashはとてもよくできていて、マウスやキーボードで感覚的に、GUIによって作ることができ、かつアニメーションができる。デザイナーには非常に使い勝手がよかった。
簡単なサイトであればコードはほとんど書く必要がなく、ノーコードのツールに近かった。
プラットフォームの問題。
また、Flash自体がプラットフォームとなるので、デバイスがMacでもWinでも、ブラウザがInternet ExplorerでもChromeでもSafariでもFirefoxでも、ユーザー側がFlash Playerをインストールすればそれだけでよかった。
Flashの普及率は高かった。
それはそれほど面倒なことではなく、普通に受け入れられていて、90%以上とも95%以上とも言われる普及率があった。なので、いわゆる「ブラウザ対応」がほとんど必要なかった。
数年前までネット上に普通に存在しており、Yahooのトップページのバナーや、WordPressのプラグインにもよくあった。
それがどうだろう。2021年現在、Flashで作られたサイトは全く見当たらない。
全盛期から、わずか10年程で。
Flashは消えてしまった。Sassはどうだろう？
FlashとSass。
- AppleやGoogle、Microsoftが対応をしなかった。
- Flashではなく、HTML5が採用された。
- そしてiPhoneやAndroidのスマホは普及した。
SassはFlash同様、ブラウザやデバイス、サーチエンジンを作っているプラットフォーム企業が対応していない。
これが全てではないが、このような場合、わざわざ使う必要性はどこにあるのだろう。
ユーザーがサイトを見ている時に「お、これはSassだな！」なんて思うだろうか？
WebサイトはHTMLでできている。
HTMLの重要性。
世界中にあるWebサイトはほぼほぼHTMLでできている。個人的にはHTML以外でできているサイトはほとんど見たことがない。
かつてのFlashもまずHTMLがあって、Flashプレイヤーがあって、その中でActionScriptという言語で動いていた。
WordPressのファイルはPHPでできているが、そのPHPも結果的にはHTMLの中で働いている。JavaScriptもそう。
当たり前なのだ。WebサイトはHTMLによってできているのだから。
W3CはやWHATWGは、Sassの勧告はしていない。
世界最初の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のものがそのままリンクされている。
初期のWebサイト。
Webサイトというよりも、Webページといった感じである。DOCTYPE宣言やhtmlタグはないが、HTML（HyperText Markup Language)の基のテキストとリンクである。
（※スイスのCERNも日本のKEKも物理学関係、素粒子レベルでの研究機関なので、大衆向けに開発されたサイトではなく、シンプルなテキストとリンクで構成されている。）
- 世界最初の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」では、2020年にSassは非推奨と発表している。Sassのマイナス面として、Sassはスピードが遅いということがあげられていた。
引用元サイト： Deprecating Sass for Shopify Themes – Shopify
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でもほぼ使わず、もちろん日常生活でも使わない。プログラミングの分野でよく用いられる、いわゆる「専門用語」、「業界用語」。
マウントを取りがたる人が使うイメージもある。
WordPressではパーツ。
WordPressのテンプレートタグでは比較的一般的な言葉である「パート（part）」が使用されており、XOOPSでは専門的な「モジュール（module）」が使われていた。
CSSの草案でもモジュールという言葉は使われてはいるが、クライアントやユーザーがCSSの草案を読むことはまずない。
少なくともHTMLやCSS、WordPressでのサイト構築の際は、日常生活と同様に普通に「パーツ」で通じる。
そのパーツの分割やネスティングレベルの構築はそもそもCSS単位で十分可能なのだ。
CSS設計？
「CSS設計」も同様に使われている。そもそもWebサイトは「HTML」という「Document Type」であり、前述の通り、「文章」だ。
サイトを設計するのは「Hyper Text Markup Language（HTML）」である。
HTMLにはアウトラインがあるが、CSSにはない。
CSSはサイトを見やすくするための装飾やレイアウトなどの補助的な役割であり、Google botは基本的にHTMLをクロールしている。
ChatGPTやGemini（旧Bard）、Copilot（旧Bing Chat）もそうだろう。
管理はHTMLとCSSで可能かつ無難。
Sassは管理がしやすいとも言われているが、それは使用する日常言語やHTML、CSSを管理できてから言うべき言葉。
Sassにハマり、HTMLのマークアップがおろそかになってはいないだろうか？
Flashのように無くなってしまったり、Shopifyのように非推奨になったらどうするのだろう？
Sassでできることは、CSSでカバーできる。
例外として、デザインもSEOもやらず、コーダー専門、プログラム専門の場合は別かもしれない。そういう局面では、Sassは便利なのだろうと思う。
ただし、2022年には、@importが廃止され、@useへ移行しなければならない。。。
…ここまで来るともう、普通にスタンダードなCSSで書いた方が自然じゃないだろうか。
Sassでできることは、今はもうCSSでカバーできる。
以上、参考になれば幸いです。
※Webデザインは実務数年、職業訓練校講師数年、フリーランス数年、計15年以上のキャリアがありますが、一気にがぁっと書いているので「です・ます調」ではありません。（元々はメモ書きでした。） ※事実や経験、調査や検証を基にしていますが、万一なにかしら不備・不足などがありましたらすみません。お知らせいただければ訂正いたします。 ※写真は主にUnsplashやPixabayのフリー素材を利用させていただいております。その他の写真や動画もフリー素材やパブリックドメイン、もしくは自前のものを使用しております。
