BEMをフォローしていますか。Yandex以外での需要はいくらですか。
BEMは、ブロック、要素、修飾子の略です。 これは、インターフェースを分割し、すべてを同じ用語で開発できる抽象化のセットです。 bem.infoによれば、BEMはコードを記述するための統一されたルールを提供し、それを拡張および再利用するのに役立ち、生産性を高め、チームワークを簡素化します。
かっこいい？ しかし、Yandexの人気を主張しないプロジェクトのタイプセッターである場合、なぜスケーラビリティとチームワークが必要なのでしょうか？ この質問に答えるには、このアプローチが策定され始めた10年前の歴史を巻き戻す必要があります。
現在BEMと呼ばれているものは、独立ブロックのアイデアに基づいています。ビタリーハリソフは、2007年にフロントエンドでの最初のロシア会議で定式化し、発表しました。 ずっと前だったので、「フロントエンド」という言葉すらありませんでした。それからクライアントサイドと呼ばれました。
その考えは、CSSをより予測可能な結果に制限することでした。 最小限のグローバルスタイルを使用し、個々のページ要素を、それを完全に記述する独自のクラスとスタイルを持つブロックにします。 要素セレクターとID、壊れやすいネスト結合-これらはすべて、単純なクラスセレクターに置き換えられました。 スタイルの各クラスはブロックです。 これにより、ブロックは簡単に交換、相互に投資でき、競合や影響を恐れることはありません。
#menu ul > li { color: old; } .menu-item { color: bem; }
その後、完全に独立したブロック（NSA）が登場しました。内部の要素には親の名前を持つ独自の接頭辞があり、ブロックの状態はクラスを再び複製しますが、接尾辞があります。 このアプローチは、クラスの冗長性の1つである現代のBEMの機能を獲得しました。
.block {} .block_mod {} .block__element {} .block__element_mod {}
この冗長性は、同じプロジェクト内の要素と修飾子の一意性を保証します。 ブロック名の一意性は注目に値しますが、各ブロックが個別のファイルに記述されていれば非常に簡単です。 HTMLまたはCSSでこのようなクラスを見れば、それが何であり、何を指しているのかを簡単に言うことができます。
最初に、NSA、次にBEMは、あらゆる規模の組版の重要なタスク、つまり予測可能な動作と信頼できるコンストラクターの作成を解決しました。 レイアウトを予測可能にしたいですか？ こちらもYandexです。 これは「モジュール性」とも呼ばれます。フィリップウォルトンは、CSSアーキテクチャで説明し、説明の翻訳へのリンクを作成しました。
数年後、Yandexは最終的にBEM表記を作成しました。 インターフェースは、ブロックに分割することが提案されました。 ブロックの分離不可能な部分が要素です。 両方に修飾子があります。
<ul class="menu"> <li class="menu__item"></li> <li class="menu__item menu__item_current"></li> </ul>
たとえば、サイト検索ブロック。 それは帽子と地下にあります-これはブロックです。 必須の部分があります。検索フィールドと「検索」ボタンはその要素です。 フィールドを幅全体に拡大する必要があるが、ヘッダーのみに拡大する必要がある場合、修飾子はこの拡大を担当するブロックまたは要素に与えられます。
ブロックを完全に独立させるには、クラスに正しく名前を付けたり、スタイルを分離したりするだけでは不十分であり、それに関連するすべてを収集する必要があります。 BEMプロジェクトには、サイト上のすべての写真を含む共通のscript.jsまたはimagesフォルダーはありません。 各ブロックを持つ1つのフォルダーには、その操作に必要なすべてのものがあります。 これにより、プロジェクト間でブロックを簡単に追加、削除、転送できます。 その後、もちろん、プロジェクトのタスクに応じて、アセンブリ中のブロックのすべてのリソースが結合されます。
BEMがYandexを超えると、最初は魔法として認識され、各ブロックの接頭辞b-
まで、逐語的に再現しようとしました。 そのような面白いカートカルト。
.b-block {} .b-block--mod {} .b-block__element {} .b-block__element--mod {}
アイデアを誤解している人もいれば、要素の要素でさえ現れました。 次に、愛好家が表記法を取り上げ、最も人気のあるものの1つが登場しました。ブロックは2つのアンダースコアで区切られ、修飾子は2つのハイフンで区切られています。 明確かつ単純に-だから私は書きます。
.block {} .block--mod {} .block__element {} .block__element--mod {}
そして、なぜこれらすべての表記法が一般的であるのか-私はプロジェクトの1人のレイアウトデザイナーだということを覚えていますか？ 覚えています。 また、BEMの前に自分で組版をしていたことも覚えています。各プロジェクトで、とても新しいものを思いつきました。 それから彼は一年前にコードを開いて驚いた-どんな馬鹿がそれを書いたのか？
たとえば、ロシア語を考えてみましょう。 人の名前や名前などを大文字で書きますか？ 書いています。 後で簡単に読むために：それはナディアまたは最高の希望ですか？ 句読点やその他の便利な規則は言うまでもありません。 たとえば、ここでは「e」の文字が柔らかくなります...では、何について話しているのでしょうか？ はい、BEM。
BEMの前には、触れてはいけないスタイルのフットクロスを使用したプロジェクトがありました。 それらは、古くからある共同アパートの壁紙のように、何年にもわたって積み重ねられてきました。 それらは最初に差し込まれ、次に干渉したものを上書きしました。 div { font-size: 80% }
-もう面白くありません。
/* */ div { font-size: 80%; }
BEMは引き続きYandexで開発され、組版の限界を超えて成長しました。再定義レベル、豊富なツール、BEMクラス、テンプレートエンジン、BEMスタック全体を操作するためのJSライブラリがありました。 BEMもジェスチャーを思いつきましたが、これはYandexに固有のまったく異なる話です。
他の方法論がありました：OOCSSニコールサリバン、ジョナサンスヌークのSMACSS、BEMバリエーション、およびフレームワーク全体。 高度な強度であっても、トレーニングプロジェクトのレイアウトには任意の方法を選択できます。
しかし、生き残ったのはBEMだけであり、それは現代のインターフェース開発の事実上の標準と呼ぶことができます。 そして、進化の最終段階は何ですか？ いいえ、もちろんです。 どのように自動化しても、BEMで多くの作業を手動で行う必要があり、競合が発生する可能性があります。
ブロックスタイルのモジュール性と分離は、さらに改善できます。 Webコンポーネント、 CSSモジュール 、多数のCSS-in-JSソリューション、さらには神が許してくれたアトミックCSSもあります。 しかし、BEMがかつてそうなった今後10年間の蓄積された問題に対する単一の解決策はありません。 それは何でしょうか？ 見てみましょう。 Webコンポーネントを使用します。
それまでの間、インターフェイスをBEMで記述すると、コードが整理され、予測可能、拡張可能になり、再利用の準備が整います。 あなただけでなく、他の人のために。