Clever Geek Handbook

人間の顔を持つBEM

音略語BEMはYandex研究所から来ました。 そこで、XSLTの場合のように、彼らはBEMのアプリケーションを絶対に上げることに決めました。YandexBEMは、Webアプリケーションのブロックアーキテクチャの単一のイデオロギーによって結ばれたユーティリティとアプローチのファミリー全体を意味します。 他の全体主義システムと同様に、BEMは厳格な開発ルールの順守を要求します。これは、Yandexとリソースが比較できない小規模プロジェクトの常識としばしば対立します。 そして、はい、あなたが公式のBEMドックを読むとき、 その同じ感覚 。







しかし、インテリジェンスと無制限のタイムラインの圧力の下で、大規模システムの進化の間にしばしば起こるように、技術的なダイヤモンドが生まれます。 はい、BEMの保存の厳密さは明らかです。 私の目の前で交わしたすべての人はすぐに幸せになりました。 しかし、喜びの最初の波の後、この発射体への2番目のアプローチが脳全体の精神靭帯を破壊できることが認識されます。 そして今では、マスタリングの複雑さ、冗長性、HTMLおよびCSSのメガバイト数の増加への注意（注意）、および他に関係のないことについての苦情がすでに聞かれています。







私は同意します。実行せずにBEMを作成して開始するのは難しいです。目の表記が傷つき、古いトリックが失敗し、体系的に考える必要があります。 そして一般的に、私たちは何年かの間BEMなしで何とかして書いたので、書きます！ しかし、入場のしきい値を簡単かつ簡単に克服するには、2回の移動だけで済みます。 まず、BEMを柔らかくして、しきい値自体を下げます。 第二に、少し自分自身を引っ張ります。 その後、移行はスムーズになり、読みやすくサポートされているCSSの時代に徐々に移行します。







どのようにしてこのような生活にたどり着いたのでしょうか？



いつものように、CSSサポートに問題がない場合は、BEMが愚かであることをenんで、技術のために記事をナンセンス、ナンセンス、異端、でたらめ、グラフォマニア、テクノロジーについて考えることをfreeしみなくお願いします。 残りの部分については、呼び出し元のCSSの柔軟性にとらわれず、しばらくお待ちください。







少しのコンテキストは、特に歴史的な私たちを傷つけません。 BEMが私たちをどこへ導くのかをよりよく理解するには、まずどこから来ているのかを覚えておく必要があります。 そこで、CSSの記述スタイルになるまでの手順を簡単に説明します。







1995：先史時代 



<font color="red">


データとプレゼンテーションが混在しているため、すべてのヘッダーの色を取得して変更することは不可能であり、情報の割合は非常に低くなっています。 そして、テーブルを思い出して写真をカットすると、6番目の探検家でさえケーキになります！ しかし、これはまだ問題ではありません。成功したサイトは、アセンブラーでも作成できるほどのリターンをもたらします。







2000：プリミティビズム 



 h3 { color: red }


ほら、一回の編集ですべてを取り、塗り直すことができます。 レイアウトはまだテーブルで行われますが、フロートは既に忍び込んでいます。 ドットコムバブルが崩壊しました。効率とサポートについて考える時です。







2005：セレクターの方法を知っています！ 



 div p.red h3 { color: red }


ここにあるのは、その火の輝きであり、私たちの多くが今日まで働くために燃え上がっている混の中にあります。 その後、このサイトはすでに、技術大学の学生だけでなく、経験豊富なシステムプログラマーでもできるようになりました。 彼らはバックエンドフレームワークを開発し、データベースを正しく設計し、負荷を維持することを学び、さらにnginxを作成しました ！ しかし、同時に、彼らはCSSを使用する方法を知りませんでした。 これがBootstrapとjQueryにつながりました。







2007： セマンティックCSS 



 .article.new .title { color: red }


ペペルスベイは熱烈なベッカーの糸に飛び込み、優しく、明るく、清潔です。 CSSのタグを削除し、HTMLでこれらの意味に目を向け、フロントエンドの健全な考え方とコードを刺激します。 作成者が意図したとおり、より多くのマイクロフォーマットと優れた優れたウェブ。







2010：Twitterブループリントで石器時代に戻る 



 <p class="text-left clearfix red">


はい、多くの善行が同志によって行われました。同志は管理者だけでなく、Bootstrapをフレームワークとして真剣に受け止めました。 当時、インターネットは指数関数的に成長しており、実際のソリューションは見ずにコピーされています。競合他社が同じ製品をリベットしているのに追いつく必要があるからです。 他にどのようなサポートがありますか-フェイスブックを切り刻む時間がある場合のみ！







2015：BEM 



 .article__header--new { color: red }


彼らは振り子をクイックスタートの横に引っ張り、引き戻しました。BEMは残忍なところまで激しく飛びました。 以前の常識に恥じて、強力な権威の背後に隠れ、CSSについては考えないために、精巧な構文の厄介な茂みに真っ向から突進する準備ができています。







主な過剰：グローバルスタイルを持たない、すべてを要素に詰め込む、他の方法論を調べない、HTMLを手で触れない、他人のCSSを持ち帰らない。 このような厳格な禁欲により、あなたは立ち上がってタラしません。







1歩後退、2歩前進



BEMにとって私たちにとって最も重要なのは：







  1. 衝突の欠如
  2. 衝突の欠如
  3. そして再び、衝突の欠如


BEMは、名前空間間の分離によって衝突が発生しないようにします。 分離モジュールの古き良き概念。 そして、一般的にSASSでは、全体のOOP。 もちろん、最初にコンポーネントの内訳について慎重に検討する必要がありますが、最初にモジュール性の賜物を喜んでみましょう。







  1. 読みやすくサポートされているコード
  2. コンポーネントの再利用
  3. テストのしやすさ
  4. JavaScript Object Harmony


以上です。 BEMの主な価値であるコンポーネントによる分離を維持できれば、コンポーネント自体の内部で何でも作成できます。 すべてのルートスタイルを制御する場合、つまりすべてを所有する場合、すべてのコードが名前空間に分割され、それらの外側にセレクターがない場合、啓発に到達し、すべてを購入する余裕があります。







不可能ですが、本当にしたい場合は...



BEMを人間化するにはどうすればよいですか？ しかし、それは非常に簡単です。少しリラックスして、常識に戻り、実験の楽しさを覚えておく必要があります。 単純なものから複雑なものまで、明白なものから興味深いものまで。







ダブルアンダースコアを参照



CamelCaseブロック表記は、熱心なC-plus-pluses / javascriptists / rubistsの目を楽しませ、ブロックと要素を混同しないようにします。 







 .Article { … } .Article-title { color: red }


もう少しすると、セクシーなDSLハックと非常によく似たものになります。







ラコニック修飾子



「名前空間の境界に違反しない」というルールに従い、ノードごとに2つのクラスではなく、個別の要素に対して各ブロックを選択する場合： 







 <div class="Box Article">


2つのノードを2つのクラスにします。 







 <div class="Box"><div class="Article">


その後、修飾子の命名を通常のものに単純化できます。 







 .Article.new { … }


そして、 is-



にis-



プレフィックスを追加すると、スタイルを直接声に出して読むことができます： 







 .Article.is-new { … }


もちろん、これは修飾子のプレフィックスの問題ではなく、これは単なる素晴らしいボーナスです。 主なことは、必要な場合でもBox



ブロックとArticle



ブロックが競合しないことですBox



モジュールとそのスタイルが異なる優先度を取得する前にArticle



モジュールがロードされる場合があるため、バグをキャッチする必要はありません。 しかし、これはすでに明らかです！







カスケード



CSSをBEMに返すことができます。 







 .Article.is-new .Article-title { color: red }


幸いなことに、定義上、単一のBEM添付ファイルを超えることは許可されない（HTMLツリーの構造を繰り返さないでください）ため、これはすでに不可能です。 







 .Article .Article-title .Article-name { … }


そしてもちろん、他の誰かの名前空間に完全に干渉することはできません。 







 .Article .SubmitButton .Icon { … }


時々、古い悪い習慣のために、私は本当に、本当にこれをやりたいです。 しかし、できません。 カオスとのバランスを保つ必要があります。そうしないと、BEMの完全性の基盤が崩れ、すべての努力が無駄になります。







ArmorDarksの賢明な発言とビンテージの鋭い冗談は、そのような修飾子を使用してツリーがスタイルを設定しないという事実に注意を払うことを読者に強いるだけです。そのような修飾子を含むノードのすべての子要素は壊れます。 木をより厳密に定型化する-正しい場所に。 ウェブ上で再帰構造を使用している読者は、毎日CSSカスケードを楽しんでいると思います。







BEMを使用しないでください



はい、プロジェクトで常にBEMを使用する場合、BEMを使用できない場合があります。 シートコンポーネントでは、BEMの原則に従うことなく、自由形式のCSSを使用できます。 このような「いたずらな」コードを独自のブロックアイソレーターに詰め込めば十分であり、次のように記述できます。 







 .WYSIWYG { h1 { … } p { … } ul li { … } }


他のモジュールの厳格な文化は、 WYSIWYG



モジュールの内部問題を妨害することを許さず、すべてがうまくいきます。 もちろん、他のコンポーネントを「いたずらな」コンポーネントに入れることは、衝突の可能性なしでは機能しません。そのため、そのような「いたずらな」ブロックはコンポーネントツリー内でのみ残すことができます。コンポーネントにネストすることはできますが、コンポーネントをネストすることはできません







このトリックは、予測不可能なユーザーコンテンツを埋め込むときにのみ役立ちます。 jQueryプラグインはブロックアイソレーターで簡単にラップでき、ページ全体でCSSの臭いがしません。 テーブルのテーブルのテーブルテーブルなど、非常に大きなコンポーネントもあります。BEMを厳守することで、プレフィクスのくびきの下にレイアウトデザイナーが生き生きと埋められるため、Bootstrapを使用する方が安価です。 また、複雑なフォームが発生します。これは、絶縁体ブロックにシート要素を作成してから考えるのにも便利で高速です。







基本スタイル



これは、フォントサイズ、先頭、リンクの色、リストの箇条書き、およびその他のリセット/normilize.cssを指します。 継承されたスタイルのほとんどは、各コンテナのこれらすべてのスタイルのハード再定義によってのみシールドできます。 これは、完全にポータブルなコンポーネントの普遍的なライブラリで世界を征服することを計画していない人にとっては冗長に思えます。 風車との戦いにエネルギーを費やすよりも、テキストウェブの不完全さを我慢する方が便利な場合があります。







これを受け入れると、古き良きSMACSSスタイルの分離アプローチがBEMにうまく移植されていることが明らかになります。 基本的なスタイルはそのまま残ります。 レイアウトは、特別な非リーフコンポーネントになります。 モジュール、コンポーネント、ブロックです。 状態は一対一の修飾子に投影されます。 BEMのテーマのサポートは、一般的にネイティブのようです。 そして、最新のアプリケーションの状態はドメインロジックによって制御され、Reactを介してモデルをレンダリングする必要があります （jQueryを使用しないでください！）。







合計



そして今、すべてが怖いものではなく、なじみのあるものになりました。 人間の顔をしたBEMは、意味的に正しいHTMLの古き良きCSSであり、維持、記述、圧縮、実行が簡単であると言えます。







裸のBEMはプロクラステアのベッドですが、理解して受け入れて仕上げると、戦闘機の座席になります-少し混んでいますが、飛ぶことができます！







道路に呼ばれた手紙



@ArmorDarksの書き込み：







あなたが興味があるかもしれません： 名前空間を持つより透明なUIコード

ありがとう、それはなんて面白いの！







私が理解している限り、説明されている手法は、完成したCSSを使用して補充する、読みやすいHTMLの作成に役立ちます。 たとえば、ユーティリティクラスu-font-size-large



がノードに適用されてフォントが大きくなり、 t-light



によりボタンの背景が明るいテーマが適用されます。 一般に、CSSルールのセット全体を知っている場合、HTMLコードは非常に簡単に読み書きできます。 ただし、同じ優先順位のスタイルを混在させる場合、すぐに必要になることがあり!important



、これは許容可能なアプローチとして記事で説明されています。 私はこれを理解できません、 イサガラエフ は私たちを異なって育てました 。







スタイルがHTMLから厳密に分離されていることにBEMで感動しました。 CSSはまだ知られ、理解される必要があるので、CSSのスタイルに関するすべての作業を最終的に削除してみませんか？ たとえば、記事のタイトルに.u-font-size-large



を使用する場合、次のようになります。 







 %u-font-size-large { font-size: x-large } .Article-title { @include %u-font-size-large }


この記事では、スタイルのさらに小さな編集が必要になる場合があります。 そして、著者は、そのような小さな編集が設計の問題を示していることにすぐに正しく反対します。 ただし、そうである必要があります.u-font-size-large-xx



を追加し、あらゆる種類の.article__title--large-xx



、 .post__title--large-xx



、 .user__title--large-xx



を作成する必要はありません。 ここでは、明示的と暗黙的のBEMの側にいます。その理由は次のとおりです。







最初に、インスペクターに触発されたエイリアンコード<div class="Article-title is-xx">



を見つけました。最初のスタイルは、最も具体的な修飾子に過ぎません。 .u-font-size-large-xx



は、少し考えて.u-font-size-large-xx



があります。 次。 @extends .u-font-size-large



継承を通じて.Article-title.is-xx



を定義した場合、インスペクターで.u-font-size-large



と同じスーパークラスを使用する他のブロックの両方を見ました。 そして、おそらくこの場合により論理的な@include



を好んだなら、あなたはすでにArticle.scss



ファイルにすぐにジャンプしており、それはあなたの修飾子の論理であり、おそらくもっと複雑ですが、SCSSに関しては視覚的です。







第二に、異なる.u-*



組み合わせについて考える必要はありませんが、これらはすべてこの特定のブロックのためのものです-それらはArticle.scss



ファイル内にあり、正しいセマンティクスを保証します。 多少冗長ではありますが、目の前にあるライブラリの修飾子のすべての可能な組み合わせ。 これは節約の決定論だと思います。 これは、Go vs C ++です。







第三に、スタイルが変更された.erb



、すべての使用場所で.erb



、 .inc



、 .php



、 .js



テンプレートに移動して、 .u-font-size-large



を新しい.u-font-size-large-xx



に置き換える必要はありませんArticle



コンポーネント、SASSを再コンパイルするだけで十分です。 もちろん、ドメインエンティティの新しい状態に意味的に新しい修飾子を追加する場合、テンプレートを修正する必要があります。 しかし、これはすでに正当な理解可能な編集であり、コミットに適切なコメントがあり、CSSを参照せずにテストされた新しい状態のドキュメントに行があります。







第4に、複数の修飾子（1つのコンポーネント内）を混合し、必要に応じて変更、削除、リファクタリングを行うことができます。他のコンポーネントのコードを読み取らず、壊れたテストについては考えません。 難易度は指数関数的に低下します。







また、あまりにも頻繁に変更されるか、多くの要素や修飾子が含まれる予測不能なすべての場合、名前空間を除き、BEMのすべての法則に違反するリーフブロックがあります。







おかげで、雪崩はなくなりました。







@ArmorDarksの書き込み ：







このアプローチ（ o-btn c-btn c-btn--positive qa-modal-accept



作成者 ）を使用すると、CSSの新しい行を1行も書かずに、ほとんどの一意のページを作成できます。

ここにキーフレーズがあります、彼女に感謝します。 これは、最終的に分水界、真ん中の深by、州境、イベントの地平線です。 このフレーズが、レイアウトに対する2つの完全に反対であると同時に同等かつ補完的なアプローチ間の利害関係を推進します。 個人的には、「CSSを変更せずに1年間、複雑なプロジェクトを何年も維持および拡張する」という熱狂的な側面と、「CSSに触れることなく長年にわたって強固な基盤を準備し、その上に大規模なアレイを構築する」というあなたの極端な立場にいます これは、フレームワークに対するパターンのようなものです。 抽象対コンクリート。 アプローチとしてBEMを使用すると、人々はフレームワークのようなコンポーネントライブラリを構築します。 アプローチに関する記事。 著者がカテゴリー理論のコースを受講する時が来ました。







ところで、Bootstrapのドキュメントが正しく示唆しているように、このような基本的なCSSフレームワークは、CSSおよび<font>



がWebである前と同じように読み取り専用である必要があります。 CSS うまくいきました。 しかし、プロセスレベルで、つまりビジネスの要求で、そのようなCSSフレームワークの変更を引き続き許可する場合... GOTO 1



。







More articles:


All Articles