BEMとSass。やりすぎなSassやBEMたちと、やりすぎたclassセレクタ。|デザイナー、コーチ、ディレクターズメモ|井川igawa.

Memo

BEMとSass。やりすぎなSassやBEMたちと、やりすぎたclassセレクタ。

HTMLとCSS。やりすぎなSassやBEM。

BEMとSass。やりすぎなSassやBEMたちと、やりすぎたclassセレクタ。

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点以上を取ることは可能だ。証拠があるので、証明もできる。

BEMやSassよりも、IDやレスポンシブ


やりすぎなSassやBEMたち。

そもそもBEMやSassは、コーディングがやりやすい、管理がしやすい、という観点から普及していった。多くのコーダーたちや新人コーダーたちは、革新的もしくは盲目的なマインドで.cssファイルや.scssファイルを書いていったのではないだろうか。

日々の業務の忙しさと経験不足の中で、先端的なテクニック、スマートなコーディング、などの、キラりとしたエッジに包まれたような幻想感に駆られ、そして行き過ぎてしまったのかもしれない。また、知ってか知らずかガラパゴス化しているのかもしれない。

そう言った場合、時にとんでもないことが起こってくる。例えばその結果が下記のような.htmlファイルだ。

破綻したコーディング。これではclassセレクタがとんでもないことに。

頑張ったり、試行錯誤してclass名を考えているのは伝わってくるが、ユーザービリティ的に正しいとは言えず、汎用性もあるとは言えないのでは。

やりすぎなSass、不要なBEM、不要なclass。

画像出典:https://qiita.com/102Design/items/d61a2c4512eaf331df66

上記サイトでも指摘されているが、「破綻している」のだ。あまりに盲目的になってしまい、視野が狭くなり、全体の設計が「破綻している」のだ。コーディングの全体像も向こう側も見えていない。

このように書いてしまうと、class名がHTMLのタグや文字列よりも遥かに多くなってしまう。逆にメンテナンスがしづらい上、ブラウザが読み込むHTMLのバイト量も肥大する。全体が見えていないので、本末転倒な結果となってしまっている。

ハイフンはダブルクリックで選択できないのでそもそもid名やclass名の指定には向いていないとも言える。デベロッパーツールで検証してみても、class名が長すぎると構造が非常にわかりにくい。

SassやBEMは、CSS学習の勘違い


そもそも誰のためのサイトなのか?

ユーザービリティ。ユーザーファースト。

サイトとは、インターネットを通して、言葉や画像、動画や音声などの情報をユーザーへ伝えるためにある。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にしてもそうだ。関係がないのだ。

商用サイトを想像してみると明確だ。顧客は商品や情報のやり取りをしたいのであって、それらを運ぶ車や回線が旧型であっても新型であっても、スムーズに手元に届けばその経路のスペックは別に気にはしない。

SEOにも無関係。もしくはデメリットの可能性も。

BEMもSassも、ユーザーやSEO対策には0に近いレベルで意味がないのだ。(ある程度のビッグキーワードで検索順位10位以内レベルのサイトを複数運営しているが、SassもBEMも使用していないので裏付けがある。)

誰のためのサイトなのか?
一度、検証してみてはどうか。

BEMやSassよりもユーザーファースト


疲れた時は、栄養を。
ポスト投函で届く、人気のブドウ糖です。
砂糖の代わりにコーヒーや紅茶などに。

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

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

お問い合わせ CONTACT..

    Name(required)お名前 (必須)
    Furigana(required)ふりがな (必須)
    Email(required)メールアドレス (必須)
    Phone Number(required)電話番号 (必須)
    Message(required)ご質問・ご要望 (必須)


    免責事項について

    • 事実や経験、調査や検証を基にしていますが、私はただの人間です。万一なにかしら不備・不足などがありましたらすみません。お知らせいただければ訂正いたします。
    • 万一損害・トラブル等が発生した場合でも、一切の責任を負いかねます。