なぜSassが実務で使用できないCSSなのかを徹底検証-Web制作オンライン学習と企業ネットコンサルティング-WIING MEDIA

2023.03.09 Thu 2023.05.03

なぜSassが実務で使用できないCSSなのかを徹底検証

Web制作

なぜSassが実務で使用できないのかを徹底検証のイメージ

Sassって本当に利用すべきなのか

あなたはSass(サス)をご存じでしょうか。または利用したことはありますか。

知らなかったかたも、採用を検討される方にも、ぜひ有用な記事になる視点でSassについて当社独自の見解などを交えてご説明させていただきます。

HTMLコーディング業務などをされている方であれば名前ぐらいは聞いたことも多いかもしれませんが、SassとはWebサイトの装飾マークアップに使用されるCSS(カスケードスタイルシート)の拡張された記述方法といえます。

Sassは”Syntactically Awesome StyleSheet”の略称で”構文的に素晴らしいスタイルシート”という意味の頭文字をとった名称です。

CSSは主にWebページのHTMLコードの表示方法や装飾を指定する仕様となっており、W3Cという世界共通規格が勧告している記述方式で、Sassはその記述ルールをさらに入れ子的なオブジェクト指向型に近い感覚で実装することが可能に記述できる仕様とされています。

SassにはSCSSとSASSという2種類の記述方法があり、どちらも入れ子的なオブジェクト指向記述が可能ですが、SCSSの方法が一般的に使用されることが多く、CSS記述では必須であるコロン(；)を省略した入れ子記述が可能な点が大きな特徴となるようです。
また、別途アプリケーションを導入して都度記述データをコンパイル(変換)する必要があり、テキストエディタでも編集可能なCSS記述とは異なる点があります。

CSSは元来が入れ子指定が可能で変則的なオブジェクト指向の組み合わせが可能な記述仕様です。ではなぜさらにSassのような入れ子での記述が特長として利用が促されているのでしょうか。

今回は実際に数百サイトの制作経験からもとに、Sassをあまり知らなかった方から利用することを検討されている方まで、Sassを利用した方が良いかどうかについて検証させていただきました。

そもそものCSSスタイルシート

ここではまず、CSS(シーエスエス)について理解と再認識をしておくことにいたします。

CSSとはCascading Style Sheet(カスケーディング・スタイル・シート)の略称で、ホームページなどで仕様されるHTMLコードのビジュアルの見栄えを良くして装飾することを主な目的として仕様される、HTMLマークアップ記述の世界共通の言語となります。

CSSの記述だけでは意味を持つことはなく、HTMLタグに対してセレクタという名前で指定をすることで、CSSセレクタ内で指定されたプロパティ(大きさや色など)の属性値(数値や形状などを指定)の内容が反映されて、Webページ内のHTML記述内容に色や大きさ、動きやアニメーションなどの様々な描写を指定することができます。

そもそもが入れ子的な記述をすることはプロパティで指定することが可能で、プロパティや属性値などの変更も、実質的にはHTML編集ツールであるDreamWeaverで、より素早く簡単に構造化されたデータと同等にマークアップや記述編集することが可能な言語です。

CSS自体がすでに十分な仕様設計

コンパイルって何？

今回の”なぜSassが実務で使用できないかを検証”の最も大きな理由のひとつであるコンパイル(言語変換)について考察してみます。

通常CSSはEdgeやChrome、FirefoxやSafariなどWebコンテンツを閲覧するためのWebブラウザというミドルウェアのようなプログラムで読み込むことで実行され、ブラウザ上でWebコンテンツを表示することが可能です。

ところがSassを利用したCSSマークアップの場合、そのままWebページに読み込むことができずに、一度SassをCSSに変換するためのコンパイラというアプリケーションが必要になります。

コンパイル自体はまったく大変な処理ではないものの、Sassで記述されたCSSは、実行環境で観るためには、都度コンパイルする必要があります。

コンパイル自体が実質的な2度手間になっている

それでだけではなく、出力されたCSSファイルは直接編集することは可能ですが、実際ひとつの実行結果を得るために、2種類の記述と元ファイルが存在することになります。

大抵のファイルは一元的に管理することが望ましいわけですが、この場合は2種類の2言語によるバージョン管理が必要になり、どちらかを個別に編集した場合は、同期がとれない状態になってしまいます。

コンパイル自体は、アウトプットしたデータが不可変的なデータであることには適しています。例えば動画ファイルのような動画編集ソフトでも編集ができて、出力されたmp4ファイルでも編集ができてしまう場合、ファイル管理や工程管理、効率的な視点からもあまり好ましい制作フローでないように見受けられるのですが、いかがでしょうか。

CSSはすでに合理的な記述仕様となっている

Sassのメリットとデメリット考察

ここではSassのメリットとデメリットについて言及してみます。

Sassの入れ子記述のメリットについて

CSSは基本的にプロパティという装飾指定を個別に記述する必要があります。
文字を三段階の大きさに指定したい場合は3つのプロパティ記述が必要になります。

その点Sassの場合は一つの文字プロパティ記述の中に3つの文字サイズの指定をネスト(入れ子)にすることができて、修正や属性値の変更が楽でしやすいといわれています。

しかし、記述方法としては入れ子になっているだけで、結果的には3種類の記述がされているため、CSSコンパイルされた時は同じ内容が出力されます。

DreamWeaverなどの専門編集ツールであれば、この入れ子記述の意味はほぼなくなり、ダイレクトにプロパティを指定することは可能なので、ちょっとした属性値の変更も直接修正してすぐに反映することが可能です。

また別の人が修正する場合にも、テキストエディタなどですぐに編集して同一ファイルとしてバージョン管理が可能なため、より対応スピードは高くなれるでしょう。

果たしてSassの入れ子記述のメリットは？

このように運用面においては、入れ子記述が可能な点に大きな利点は感じられないように見受けられました。

レスポンシブ対応時のメリットについて

さらにSassの入れ子メリットとしてレスポンシブ記述も入れ子にできるため、プロパティの管理がしやすくなると紹介される場合があるようです。

レスポンシブ対応とは、おもにブラウザのウィンドウ横幅サイズまたは表示画面の横幅サイズにあわせてCSSプロパティの条件を分岐させる記述対応をすることです。

具体的には＠media screenのカギ括弧内に表示サイズによってCSSセレクタのプロパティや属性値をすることでレスポンシブ表示を制御できますが、その記述をセレクタごとに入れ子して管理ができる点となります。

CSSセレクタをmedia screenで制御する利点はない

セレクタごとにレスポンシブのプロパティを設定できるとして、HTMLマークアップ上の管理について考えてみます。

レスポンシブ対応の表示確認には、各表示サイズごとに確認してCSSセレクタのプロパティを調整することになります。

ということは、表示サイズごとに各セレクタがまとめて記述されているほうが望ましく、CSSセレクタごとにサイズごとの表示記述がまとめられている場合の不便性については、おおよそ予測していただくことができるといえるでしょう。

セレクタのネスティングによる命名ルールの意義

Sassではセレクタのネスティング以外に、セレクタ名を継承したり任意の別のセレクタ名と結合したり、セレクタ要素同士を繋げたりすることが可能です。

結合するには”＆(アンパサンド)”使用して指定します

ただし、基本的にはCSSルールを別の記述方法にするだけなので、実際に記述するコード量が極端に減ったり、出力されるCSS記述が特別な記述方法で出力されるわけではありません。

セレクタ名の親子要素の概念は、BEM(Block　Element　Modifier)というCSS命名規則などで利用しやすい手法となりますが、もともとCSSではBEM的な命名規則でマークアップすることも前提とされているケースが多く、あらためてアンパサンドで入れ子記述をしてコンパイルする利点は、やっぱり見当たらないといえるかもしれません。

また、セレクタ名の命名規則の親子関係を分離することで、逆にわかりずらくなると言っても良いかもしれません。

CSSのセレクタ記述は、セレクタ自体のプロパティのオブジェクト指向に大きな利点があると数多くの実務上で認識させられることが多く、セレクタ名の命名規則やネストによる親子関係のオブジェクト化に大きなメリットや業務効率上のベネフィットがあると実感できる点はあまりないように見受けられます。

むしろ運用上は、都度分離されたセレクタを個別に編集する必要が生じ、通常のCSSよりも余計に工数が発生しやすいでしょう。

DreamWeaverであれば、セレクタ名はダイレクトに指定および検索することが可能なので、分離分割して管理する上でも、CSSはすでに十分に合理的な仕様設計になっているといえるでしょう。

mixinという関数的CSSアットルール

Sassの最大の特長のひとつと言える点に、mixinというアットルール(＠規則)記述があります。

mixinはSassのみで使用できるCSSの＠規則で、クラスタをよりプログラミング的に使用することが可能になります。

CSSセレクタを関数や引数などを持たせ、バックエンドで使用させるグローバル関数のように使用することができ、よりオブジェクト指向でCSSを利用したい時には良いかもしれません。

他のセレクタ内にもmixinで指定したクラスタは共通関数定義のようにインクルードすることができます。

CSSに関数の概念は不要かもしれない

ただし、CSSの特性として、親要素のセレクタ属性値や汎用タグの属性値は基本的に子要素に継承されるため、CSSの優先序列や記述ルールをしっかり把握しておけば、関数として呼び出す必要性があることは、ほとんどないといえるかもしれません。

たとえば、bodyタグ内にfont-size:1.0rem;と指定しておけば、原則的にタグ内の要素はすべて自動的に適用されると考えていいでしょう。ひとつのセレクタ指定がすでに共通関数をコールしていることと同じになるからです。

あらためてmixinで共通のプロパティを使用して、わかりにくい記述構成化をしたうえでコンパイルする必然性がなかなか見つからなかったりします。

mixis＠規則はSassのみで使用可能

結論としてSass

今回の記事ではSass(Syntactically Awesome StyleSheet)の特長や実務的に利用すべきかどうかという点を中心に検証させていただきました。

決して、Sass自体の仕様について賛否を決めようというわけではなく、当社において実務上利用するべきか、または業務対応範囲としてSassを採用すべきかという点において主観的な観点から考察させていただいております。

結論としてSassは利点を見いだせない

上記のような結論に達しました。

コンパイルという一つの処理もそうですが、Sassに限らずあらためて記述した内容を再度構築し直すという点に何らかのメリットがあれば良いのですが、当社の実務事例上もほぼベネフィットがないと判断されたからです。

車輪の再発明以前の問題に

同じ技術やソリューションを最初から作り直すことなどを”車輪の再発明”などと表現されることがあります。

Sassに関しては、逆に煩雑に管理しずらくなっているのではないかという点が多々見られて、BootstrapやTailwindなどのCSSフレームワークやBEM規則なども含め、CSSおよびDreamWeaver自体の特性をある程度認知して利用できる環境であれば、ほぼ工数やファイル管理対象をいたづらにふやすだけでWebメイカー側にも発注事業者側にも、ほとんど受けられるべきメリットはないといえるでしょう。

ですので、当社の結論としてはSassの不採用となり、業務的な依頼をご相談いただく場合にも、原則的に非対象および対応不可の仕様ということで定義させていただく結論に至りました。