Clever Geek Handbook

「BEM'a問題」の問題は何ですか？

30行のコードの週が終了したようです。その代わりに、 BEMの週が明らかになったようです。 さらに、かなり面白いトピックのシーケンスを追跡できます。



そして、コメントで最も興味深いのは、いつものように、純粋なホリバーです。 しかし、何のために？ BEMの方法論に神聖な信仰を抱く人もいれば、セマンティクスの強奪者としてそれを軽spする人もいます。 私は、ホリバー全体の本質に関する私の見解を述べ、まず、自分自身の宇宙におけるBEMの位置を明確にすることを試みます。



実際、私はずっと前にBEMに興味を持ち、アイデアを気に入って、掘り下げようとし、それを実践しようとしましたが、どういうわけかうまくいきませんでした。理由はわかりません。 いくつかのアプローチを行いましたが、最終的に私のプロジェクトは、BEM'aを実装しようとするひどい混乱と、「クリスタルセマンティクスHTML + CSSのアイデア」に変わりました（これは、BEM'eに失望しました）。 実際、これまでのところ私は悲しみを喜ばせ、プロジェクトに取り組むことの苦痛に日々の喜びをもたらしています 。 カタからのポップアップ記事とそれらへのコメントは、イデオロギー、方法論、技術などのトピックに関連して、レイアウトのセマンティクス、ブラウザの設計、BEM、プリプロセッサ、およびすべて、何らかの形で感情の嵐を引き起こしました。 BEMを適用する私の個人的なアプローチは失敗しましたが、方法論を適用するための論理的な正当化が頭の中でまだ歩き回っていたので、各記事とすべてのコメントで、私の質問に何らかの形で答えて最終的に形成される真実を見つけようとしましたBEMに対する私の個人的な態度。 奇妙なことに、ある時点で、これが起こりました。 それがどのように起こったのか、なぜあなたに伝えようとするのか。



典型的なホリバーを考える



俳優


セマンティスト-BEMの拒否。

BamerはBEMの支持者です。



第1幕：始まり


セマンティスト


メニュー構造を書きましょう。 

<nav> <ul class="top-menu"> <li><a href="/home/">HOME</a></li> <li class="active">ABOUT US</li> <li><a href="/services/">SERVICES</a></li> <li><a href="/partners/">PARTNERS</a></li> <li><a href="/customers/">CUSTOMERS</a></li> <li><a href="/projects/">PROJECTS</a></li> <li><a href="/careers/">CAREERS</a></li> <li><a href="/contact/">CONTACT</a></li> </ul> </nav>


メニューを作成し、それにクラスを固定しました。 

 nav a { text-decoration: none; } nav ul { margin: 0; padding: 0; } nav li { list-style-position: inside; font: 14px 'Oswald', sans-serif; padding: 10px; } .top-menu li { display: inline-block; padding: 10px 30px; margin: 0; } .top-menu li.active { background: #29c5e6; color: #fff; } .top-menu a { color: #b2b2b2; }




ベーマー


構造とカスケードに依存します-最初の編集ですべてがバラバラになります。 それはより正しいでしょう：

HTML： 

 <div class="b-menu"> <a href="#" class='b-link b-link_menu b-link_menu_active' >HOME</a> <a href="#" class='b-link b-link_menu' >ABOUT US</a> <a href="#" class='b-link b-link_menu'>SERVICES</a> <a href="#" class='b-link b-link_menu'>PARTNERS</a> <a href="#" class='b-link b-link_menu'>CUSTOMERS</a> <a href="#" class='b-link b-link_menu'>PROJECTS</a> <a href="#" class='b-link b-link_menu'>CAREERS</a> <a href="#" class='b-link b-link_menu'>CONTACT</a> </div>


CSS： 

 .b-menu { margin:0; padding:0; list-style:none; width:100%; display:table; table-layout: fixed; } .b-link_menu { text-align:center; color:#bfbfbf; cursor:pointer; font-size:14px; height:38px; background-color:#f3f3f3; line-height:38px; border: 1px solid #e7e7e7; display:table-cell; text-decoration: none; } .b-link_menu_active { color:#fefefe; background-color:#29c5e6; border:1px solid #29c5e6; }


このアプローチを使用すると、スタイルを分解せずにHTMLの構造を変更する必要がありません。



Act II：誤解


セマンティスト


たくさんのクラスを作成するポイントは何ですか？ インラインスタイルを登録する方が簡単で短くありませんか？ なぜCSSファイルを膨張させるのですか？ 何も明確ではありません！



ベーマー


ブラウザによって処理される場合、クラスは可能な限り具体的であり、研究により、 これが現代の世界で役割を果たすことがより早く解決されることが示されています。 インラインスタイルはプロジェクト全体に広がり、そのサポートは可能な限り困難になります。 変更を加えるときにレイアウトを埋めるよりも、CSSファイルを膨らませた方が良いでしょう。



セマンティスト


私にとって、HTMLとCSSの両方のセマンティクスと可視性は、ブラウザーではなくコードを記述するため、ブラウザーがCSS命令の処理に費やす時間よりも重要です。 さらに、このような多数のスタイルは、HTMLを作成してプロジェクト構造にバインドするときに忘れがちです。 レイアウトが崩れないように、セマンティクスについてよく考える必要があります。



Act III：別の次元への移行


ベーマー


まだ手でHTMLを書いていますか？ 結局のところ、bemhtmlやbemjsonなどの素晴らしい要素があります-クラス（付随的に繰り返し使用できる）、ドキュメント構造とコンテンツにおけるそれらの位置、およびツールがHTMLマークアップを生成し、すべてを棚に置きます。 したがって、HTMLに直接触れる必要はありません。



セマンティスト


なぜツールを使用する必要があるのですか？ HTMLとCSSのプリプロセッサを使用した方が効果的です。効果は同じですが、コードが小さくなり、すべてがより明確で視覚的になります。



Act IV：インターチェンジ


ベーマー


もう1つは「BEMに入らなかった」ため、何らかの理由でプリプロセッサを引っ張り、一般に暖かさとソフトを比較し、大規模なプロジェクトに無事に適用できる方法論を提供します。



セマンティスト


それでも、あなたのアプローチの利点はわかりません。すべてが複雑になり、いくつかの追加ツールで大きくなりすぎます！ 私は数年間働いており、何も落ちていないので、私のアプローチは優れています。



*さまざまな角度からの見解の相違を強調するために、ホリバーの説明の多くは、意図的に誇張され、言い換えられ、文脈から除外されています。



「BEM'aの問題」



上記のすべてのホリバーの意味は、基本的に「ウォームとソフト」を比較するという議論にあります。単に「ウォーム」と「ソフト」によって、各開発者は異なる抽象化も意味します。 そして、これがBEMと「入らない」人々の主な問題です-方法論の著者はこれら3文字にあまりにも理にかなっています。そのため、方法論で作業しなかった人々は経験の「鍵穴」を通して宇宙。 そして、なぜ彼らがそれを思いついたのか、そしてそのアプリケーションのポイントは何かを理解するために、多くの情報を読み直し、その中の因果関係を特定し、それに慣れる必要があります。 著者自身が議論の方法論の一部を切り取り、これらの異なる部分はすべてBEMと呼ばれます。



一方では、BEMは単にクラスを命名するための原則です。 「ブロック要素修飾子」というアイデアは非常に論理的に見えます。すべてのエンティティを.b-exampleブロックと.b -example__element要素で囲んで記述します 。 また、このアプローチにより、クラスの可視性を高め、名前でのみブロックに属するクラスを判別できます。



一方、BEMは独立したブロックの実装の原則です。 カスケードクラスの拒否、ドキュメント構造へのバインドの拒否、クラス名の最大の特異性-これらはすべて、絶え間なく発生する編集、再設計などを簡単に行えるようにすることを目的としています。



そして、最も興味深いのは、方法論が発展すればするほど、これらの3つの文字により多くの意味が注がれるということです。



BEM-HTML構造を作成する際の手動アプローチの放棄。 使用されるすべてのクラスをJSON（この場合は特定のBEMJSON）で記述し、ドキュメント構造とクラス関係を作成します-特別なツール（bemhtml）が対応するHTMLを生成します-すべてが素晴らしく、誰もが満足しています。



BEM-以前に生成されたHTMLで動作するJSを生成する機能。 *彼とは仕事をしていなかったので、この点については意味のあることは何も言えません。



「悪の根」



私の個人的な見解では、このような3文字の再解釈は「悪の根」であり、イデオロギーへの広範な大衆の関与に寄与しません。 誤解に陥るたびに、著者とイデオロギー家は、頭字語BEMによって特定のコンテキストでの正確な意味を説明する必要があり、多くの場合、明確に説明することはできません。



実際、これらの考えはすべて、 NSAに関連するコメントの1つによって促されました。 そして、「絶対に独立したブロック」または「歪みのないブロック」などの非常に理解しやすい用語から離れる必要があった理由は、私には完全に理解できません。追加の抽象化「ブロック要素修飾子」を導入し、毎回説明し、噛む必要があります。



この問題の論理的な解決策は、このようなグローバルな抽象化をより小さなものに分解することであると思われます。小さな抽象化ごとに用語を一貫して導入し（「BEMの球体」）、各抽象化の使用と改良。



結論の代わりに。



個人的に、私はBEMに決めました：



More articles:


All Articles