BEMとSass。やりすぎなSassやBEMたちと、やりすぎたclassセレクタ。
です・ます調の文章でなくてすみません。当初は個人的なメモ書きだったためです。
Contents - 目次
classセレクタと子孫セレクタ。
2010年頃までは、子孫セレクタの使用は普通だった。どちらかと言えば推奨されていた雰囲気があった。W3Cがそう策定しているので、自分が講師をしていた職業訓練校でもそのように教えていた。教科書に記載されており、検定試験でも出題されているのだ。おそらく今でもそうだ。なぜならW3Cが（WHATWGも）そうしているからだ。
だが近年は、classセレクタの全盛時代となっている。逆転現象となっている。
これは一体、なぜだろう？
BEMとSass。
ちょっと考えてみた。
まず一番の理由は、コーディングの際にBEMやSassの記法を用いた方がやりやすそうだから、だろう。
おそらくデジタルネイティブなZ世代のコーダーたちの多くは、HTMLやCSSを学ぶ際に、最初からBEMやSassの学習から入ることも多いのだろう。個人的にもBEMやSassの必要性について聞かれたことが何度もある
その反面、実案件でクライアントやディレクターから、Sassを使用して欲しい、BEMでCSS設計をして欲しいと言われたことは一度もない。数年前に自分がチームを組んでディレクションをした時に一度Sassを使ったことがあるくらいだ。
学校やスクールにも当たり外れがある。
学校やスクールなどでも、そうやって教えているところが多いと思われる。リアルに遭遇したこともある。義務教育の時を思い出してみてほしい。必ずしも先生だから正しい、というわけではなかっただろう。いわゆる「良い先生」に教えてもらえるのは「運」による影響が大きい。
ネット上でもBEMやSass、またそこからの派生や類似情報が錯乱しているので、独学で覚える場合も混乱するだろう。
以前の時代のように、HTMLやCSSの歴史やIE対策のハックの知識やテクニックなどを学ぶ、などよりもBEMやSassの方が重要視されているはずだ。そのような環境下で、果たして、「愚者は経験に学び、賢者は歴史に学ぶ」という格言などは知られているだろうか。
ブラウザの読み込み。
次の理由として、実はブラウザはCSSセレクタを左からではなく右から読んでいるらしいよ、ということがここ数年ネット上で広まっている。そしてそれらの記事のほとんどは、ここ2、3年前以内のものである。
ブラウザは右からセレクタを読んでいる、というレンダリングエンジンの仕組みについては、10年前の記事でもすでに言われてはいるが、当時はそのことは全くと言っていいほど注目されていなかった。
それよりもIE対策や、スマホやタブレットの急速な普及によるレスポンシブ対応が優先されていたのだ。子孫セレクタの冗長さに気づいたデザイナーやコーダーも多かったはずだが、デバイス対応による作業量が勝ってしまっていたと思われる。年齢も含め、ディレクターへと転身した方も多いだろう。
ちなみに、idセレクタや子孫セレクタを普通に使ったサイトで、PageSpeed Insihtsで90点以上を取ることは可能だ。証拠があるので、証明もできる。
やりすぎなSassやBEMたち。
そもそもBEMやSassは、コーディングがやりやすい、管理がしやすい、という観点から普及していった。多くのコーダーたちや新人コーダーたちは、革新的もしくは盲目的なマインドで.cssファイルや.scssファイルを書いていったのではないだろうか。
日々の業務の忙しさと経験不足の中で、先端的なテクニック、スマートなコーディング、などの、キラりとしたエッジに包まれたような幻想感に駆られ、そして行き過ぎてしまったのかもしれない。また、知ってか知らずかガラパゴス化しているのかもしれない。
そう言った場合、時にとんでもないことが起こってくる。例えばその結果が下記のようなHTMLだ。
破綻したコーディング。classセレクタがとんでもないことに。
頑張ったり、試行錯誤してclass名を考えているのは伝わってくるが、ユーザービリティ的に正しいとは言えず、汎用性もあるとは言えないのではと思う。
画像出典：https://qiita.com/102Design/items/d61a2c4512eaf331df66
上記サイトでも指摘されているが、「破綻している」のだ。あまりに盲目的になってしまい、視野が狭くなり、全体の設計が「破綻している」のだ。コーディングの全体像も向こう側も見えていない。
このように書いてしまうと、class名がHTMLのタグや文字列よりも遥かに多くなってしまう。逆にメンテナンスがしづらい上、ブラウザが読み込むHTMLのバイト量も肥大する。全体が見えていないので、本末転倒な結果となってしまっている。
ハイフンはダブルクリックで選択できないのでそもそもid名やclass名の指定には向いていないとも言える。デベロッパーツールで検証してみても、class名が長すぎると構造が非常にわかりにくい。
BEM？ Sass？ そもそも誰のためのサイトなのか？
ユーザービリティ。ユーザーファースト。
サイトとは、インターネットを通して、言葉や画像、動画や音声などの情報をユーザーへ伝えるためにある。CSSのclass名をわかりやすく伝えるため、ではないのだ。
HTMLやCSSの基礎・基本が身に付いていない状態で、BEMやSassを使いこなすには無理がある。
検索エンジンはBEMもSassも重視していない。
Google社のPageSpeed InsihtsでもW3CのValidation Serviceでも、BEMやSassのチェックは一切行われない。SEO的にもほとんど考慮されない。classセレクタの方が読み込み速度が速くなくからSEO的にも良い、という情報も見られるが、実際にSEOの検証をしてみるとその情報が事実ではないことがすぐに判明する。
少し離れて客観視してみてはどうだろうか。本文より長くなるほどのハイフンやアンダーバーで繋げられたclass指定をしたり、ページに1つしか使われていないheaderタグに、わざわざ「class=”header”」と振ってどうするのだ。hタグに「class=”ttl”」という名前の指定も不思議な命名だ。
hタグが何かのtitle(ttl)であるのは自明であり、むしろ、「頭痛で頭が痛い」みたいなように見えてしまう。ulの中にhタグがあるのはW3Cでは文法違反でもある。Googleのbotにとってはむしろノイズとなり、処理の邪魔となりうる可能性すらある。
近い将来、5Gの時代、class指定による数キロ数十キロバイトレベルのスピードアップは意味をなすだろうか？
検索エンジンは、HTMLよりもCSSのクロールを優先するだろうか？
BEMもSassも、ユーザーや検索エンジンは気にしない。
コーダーにはメリットもある。
BEMやSassを極めたとしても、それはあくまでもコーダーのためのものだ。ただし忘れてはならないのは、コーダーやコーダー間のためには便利なものだが、ユーザーには全く意味がないということだ。
ユーザーには無関係。
ユーザーやクライアントの方々にデバイス対応を求められることはあっても、BEMで作って欲しいという依頼をされることなどはまずないだろうし、Sassにしてもそうだ。関係がないのだ。
商用サイトを想像してみると明確だ。顧客は商品や情報のやり取りをしたいのであって、それらを運ぶ車や回線がA社であってもB社であっても、スムーズに手元に届けばその経路のスペックは別に気にはしない。
BEMもSassもSEOには無関係。もしくはデメリットの可能性も。
BEMもSassも、ユーザーやSEO対策には0に近いレベルで意味がないのだ。（ある程度のビッグキーワードで検索順位10位以内レベルのサイトを複数運営しているが、SassもBEMも使用していないので裏付けがある。）
誰のためのサイトなのか？
一度、検証してみてはどうだろうか。
※Webデザインは実務数年、職業訓練校講師数年、フリーランス数年、計15年以上のキャリアがありますが、一気にがぁっと書いています。（元々はメモ書きでしたので順次見直し、更新しています。） ※事実や経験、調査や検証を基にしていますが、万一なにかしら不備・不足などがありましたらすみません。お知らせいただければ訂正いたします。 ※写真は主にUnsplashやPixabayのフリー素材を利用させていただいております。その他の写真や動画もフリー素材やパブリックドメイン、購入素材、もしくは自前のものを使用しております。
