Sassは必要?メリットは? Sassからの卒業。Back to CSS。ブログメモ デザイナー、コーチ、ディレクター|井川

igawa design.

Memo

Sassって必要なの?CSSを忘れてない?

です・ます調の文章でなくてすみません。当初は個人的なメモ書きだったためです。

Sassで書く意味はなんだろう? なぜ、わざわざSassを使うのだろう?

Sassのメリット。

まず第一に、Sassを使用する理由・メリットは何だっただろう?
個人的には、、、

  1. 変数を使える。
  2. 関数を使える。
  3. 四則演算が使える。
  4. Sassのかっこよさげなイメージ。

この4つは大きかった。テキストや背景色などのカラーコードを変数に格納、widthの幅を四則演算、というのは非常に便利だった。そして何より4つ目の、SassのロゴやAwesomeなイメージがよかった。

mixinも最初は、便利そうじゃないか!と思った。これからはSassの時代だろう!とも感じた。

Sassのデメリット。

  1. コンパイルが必須。
  2. .scssファイルもしくは.sassファイルが必要。
  3. 多すぎるオリジナルルール。
  4. 大手サイトがSassを非推奨に。

そんなSassだが、早々に使うのをやめた。使ってすぐに気がついたのは、コンパイルの手間とそれに伴うファイル数の増大だった。Sass独自のルールや種類も多く、ひとつひとつの作業がいちいちと面倒すぎる。その時点で使うのをやめた。卒Sassだ。

ありがとうSass。CSSへのプログラミング導入のきっかけとしての影響力は確かにすごかった。


Sassのその他の特徴。

オリジナルルールとその結果。

  1. ネスティング。
  2. パーツを分割できる。
  3. 結果的にCSSとなる。

などがある。他にも色々とあるが、この3つはSass利用者であればほぼ必ず経験することだ。

この3つの特徴の中で(他に多々あるが)最も疑問となるのが、結果的にCSSになる、というところだ。

さらに生の.cssファイルと違い、サーバー上で直接編集できない.scssファイルは修正が不便だった。特に新しいデバイスが普及し、レスポンシブ対応のためにスマホやタブレットの実機でのブラウザ確認をする上で、テストサーバーや本サーバーで編集できないというのは作業上での大きなストレスとなった。


ローカル環境も必要だが、テストサーバー、デモサーバーはより重要。

ちなみに以前そのことを指摘すると、ChromeとIPアドレスでローカル環境を構築すればPCでもスマホ実機でも確認できると、ある学校で生徒さんへ教えている「Sassが大好きな先生」と出会って疑問に思ったことがある。

その「先生」はよくある卒業生から講師になったパターンであり、制作会社での実務経験はなく、おそらく実案件でのサイト制作経験のない人物だった。生徒さんをお客様と呼んだ数時間後に今度はクソ呼ばわりするというタイプで、影でのパワハラも日常的だった。

ちなみにたとえChromeでローカル環境を作ったとしても、国内シェア率が高いiPhoneのSafariが確認できないという致命的な問題をカバーできない。Chromeだけの確認であれば、デベロッパーツールでのエミュレータでほぼほぼ十分であり、逆にテストサーバー、デモサーバーを立ち上げないWeb制作会社なんてほとんど聞いたことがない。

そのような制限の多いローカル環境を構築するよりも、サーバーを用意しアップした方がずっと速く確実だ。

CSS3の登場。

そこで改めて思った。最初からCSSで書いた方がいいんじゃないか?と。ちょうどW3CからCSS3がリリースされる時期でもあった。

Sassは不要に? HTML5とCSS3の登場。


CSSはすでに進化している。

CSS3によるプログラミング。

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からSassのようなネスティングの書き方がCSSベースでできるような草案も出ている。もしかするとSassの功績なのかもしれない。

参考:CSS Nesting Module

イメージとしてCSSはSassに比べて古っぽさがあるのかもしれないが、それは錯覚で、そもそもSassの最終形態はCSSだ。

事実として.scssファイル、.sassファイルはコンパイル後に.cssファイルとなる。

GoogleやApple、Microsoft、WordPressは、HTMLやCSSへの対応はしているが、Sassの対応はしてはいない。GoogleやApple、Microsoftが作ったブラウザは、生で書かれた.scssファイルを読み込んだりしないし、WordPressもそうだ。

Sassというのはあくまでもローカルな言語であり、世界基準の言語、Web標準言語ではないのだ。

Sassは必要? Sassからの卒業。Back to CSS。

頑張って勉強しても、テストにSassは出ない。

ちょっと冷静に考えてみてほしい。

検定試験ではHTMLやCSSはごく当然に出題されるが、Sassの検定試験が不要とされている現状はなぜだろうか?

現時点では一部のコーダー間だけで通じる言語であり、残念ながらブラウザやユーザーやGoogleのbotにSassは通じない。

Sassのイメージ、いわゆるイケてる感じのイメージは、コーダーの間だけでの流行であり、実社会ではまずほとんど誰も知らない。

Sassを使わない制作会社はあるが、CSSを使わない制作会社はない。

これも見落とされている。Sassを使用していない制作会社は普通にある。そもそも制作会社でバリバリとコーディングをしている人たちはSNSなどで情報発信する時間を取りにくいので、その事実を知られていないのではないだろうか。

クライアントやユーザーに求められるのはWebサイトの見た目や機能であり、そこに直接関与しないSassよりもUI、UXを高めるCSS3でのアニメーションの方が優先される。そういう現場の実情が伝わっていないのかもしれない。

ノーコード。

近年多い、「ノーコード」についても同様だ。コードを書かなくても良いのなら、デザイナーとしては逆にその方が楽だ。歓迎されるだろう。だが、実務の現場はそうはなっていない。

本当にノーコードで済むのなら、世の中のサイトはWordPressのフリーテーマやWix、STUDIOなどありふれるだろう。でも未だそうなってはいないのは、どうしてだろうか?

Sassは必要? Sassからの卒業。Back to CSS。


Flashと、HTML5&CSS3。

以前、Flashというとても便利なオーサリングソフト、その結果としてのアニメーション、そしてプラットフォームがあった。全盛時にはフラッシャーと呼ばれるFlash専門の人たちもおり、サイト全体はもちろん、バナーなどにも良く使われていた。

Flashはとてもよくできていて、マウスやキーボードで感覚的に、GUIによって作ることができ、かつアニメーションができる。デザイナーには非常に使い勝手がよかった。コードはほとんど書く必要がなかった。

プラットフォームの問題。

また、Flash自体がプラットフォームとなるので、デバイスがMacでもWinでも、ブラウザがInternet ExplorerでもChromeでもSafariでもFirefoxでも、ユーザー側がFlash Playerをインストールすればそれだけでよかった。

それはそれほど面倒なことではなく、普通に受け入れられていて、90%以上とも95%以上とも言われる普及率があった。なので、いわゆる「ブラウザ対応」がほとんど必要なかった。

数年前までネット上に普通に存在しており、WordPressのプラグインにもよくあった。

それがどうだろう。2021年現在、Flashで作られたサイトは全く見当たらない。
全盛期からわずか10年程だ。


なぜか?

  1. AppleやGoogleが対応をしなかった。
  2. Flashではなく、HTML5が採用された。
  3. そしてiPhoneやAndroidのスマホは普及した。

ブラウザやデバイス、サーチエンジンを作っているプラットフォーム企業が対応していない。
これが全てではないが、このような場合、わざわざ使う必要性はどこにあるのだろう。

ユーザーがサイトを見ている時に「お、これはSassだな!」なんて思うだろうか?


WebサイトはHTMLでできている。

世界中にあるWebサイトはほとんどはHTMLでできている。個人的にはHTML以外でできているサイトは見たことがない。

かつてのFlashもまずHTMLがあって、Flashプレイヤーがあって、その中でActionScriptという言語で動いていた。

WordPressのファイルはPHPでできているが、そのPHPも結果的にはHTMLの中で働いている。JavaScriptもそうだ。

当たり前なのだ。WebサイトはHTMLによってできているのだから。

W3Cは、Sassの勧告はしていない。WHATWGもしていない。

W3CはSassを必要としていない。

世界最初のWebサイトはTim Berners-Lee(ティム・バーナーズ=リー)氏によってHTMLで書かれた。WWWの生みの親だ。彼はW3Cという団体を立ち上げ、そのW3CがHTML5やCSS3を作って世に出している。

普段何気なく見ているサイトを右クリックしてソースを表示させてみると、1行目に「<!DOCTYPE html>」と書かれているはずだ。その意味は、シンプルに、「HTMLの文書です」、という意味だ。

HTMLやCSSが国の憲法のようなものだとすると、Sassは地方自治体で流行っているルールみたいなものなのだ。

2021年現在ではW3Cとダブルスタンダード的な立ち位置だったWHATWGによる「HTML Living Standard」がWeb標準となっているようだが、ベースはHTML5であり、コーディング作業においては両者に大きな違いはない。

現にWHATWGのサイトのHTML文法チェッカーは、W3Cのものがそのままリンクされている。そこにSassはいない。

初期のWebサイト。

Webサイトというよりも、Webページといった感じである。DOCTYPE宣言やhtmlタグはないが、HTML(HyperText Markup Language)の基のテキストとリンクである。

出典:Wikipedia


プラットフォーマーがSass対応をしていない。

AppleやGoogle、Microsoftは、Sassを読み込まない。

  1. AppleやGoogle、Microsoftが採用をしていない。
  2. Sassではなく、CSS3が適用されている。
  3. そしてiPhoneやAndroidのスマホは普及した。

デバイスやブラウザ、サーチエンジンを作っているプラットフォーム企業が対応していない。
これが全てではないが、このような場合、わざわざ使う必要性はどこにあるのだろう。

Flashの時と似たような状況ではないだろうか?


Sassは非推奨となったshopify.


ShopifyのテーマではSassはむしろ非推奨に。

推奨されないものは使いづらく、人にも勧めづらい。

ちなみに大手オンラインストア「Shopify」では、すでにSassは非推奨となっている。Sassのマイナス面として、Sassはスピードが遅いということがあげられている。独自ルールやCSSでは必要のない過程があるのだから当然だ。


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でもほぼ使わず、もちろん日常生活でも使わない。プログラミングの分野でよく用いられる、いわゆる「専門用語」、「業界用語」だ。

Sassは必要? Sassからの卒業。Back to CSS。

CSS設計?

「CSS設計」も同様に使われている。
これらの言葉は、使っているだけでその気になれてしまうのかもしれない。

そもそもWebサイトは「HTML」という「Document Type」であり、前述の通り、「文章」だ。サイトを設計するのは「Hyper Text Markup Language(HTML)」である。

CSSは見やすくするための装飾やレイアウトが目的であり、Google botは基本的にHTMLをクロールしている。

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セレクタ。

CSSを忘れてない?

以上、参考になれば幸いです。


Webデザインは実務数年、職業訓練校講師数年、フリーランス数年、計15年以上のキャリアがありますが、一気にがぁっと書いています。(元々はメモ書きでしたので順次見直し、更新しています。) 事実や経験、調査や検証を基にしていますが、万一なにかしら不備・不足などがありましたらすみません。お知らせいただければ訂正いたします。 写真は主にUnsplashPixabayのフリー素材を利用させていただいております。その他の写真や動画もフリー素材やパブリックドメイン、購入素材、もしくは自前のものを使用しております。

デザイナー、ディレクター、講師、コーチ / 井川宜久

お問い合わせ CONTACT..

    免責事項について

    • 記事ページ(Memosのページ)は当初は文字通りメモ書きでした。その後、修正や更新をしております。
    • 事実や経験、調査や検証を基にしていますが、万一なにかしら不備・不足などがありましたらすみません。お知らせいただければ早急に対応いたします。
    • 一個人のポートフォリオサイトですので、万一損害・トラブル等が発生した場合でも、一切の責任を負いかねます。

    個人情報について

    • 個人情報はお問い合わせやお客さま対応のみでの利用とさせていただいております。
    • こちらから営業目的でご連絡することはありません。
    • ご本人様の了解や、法に基づいた理由がない限り、第三者へ開示することはありません。