💆🏽 🔢 👨🏼‍🌾 人間の顔とバックエンドの統合を備えたBEM 👨‍👧 👐🏿 👨🏽‍🎤

最新のWebプロジェクトのレイアウトは複雑で、長く、高価です。 IEの自動更新への移行、HTML5、Win XPのサポートの終了により、ポニーと虹のある素晴らしい国に住む必要があるようです。なぜ簡単にならなかったのですか？

HTML5とCSS3により、デスクトップアプリケーションの複雑さと応答性とほぼ同等のUIをWebで作成できるようになりました。 HTML、CSS、JSは何倍も簡単です。以前は、 styles.css 、 stupid-ie-must-die.css 、 scripts.jsの 3つのファイルで十分でした。現在、スクリプト、スタイル、ダウンロード可能なフォント、写真の数は数十と数百で測定されています。ファイルシステム内のこのすべてのジャンクの縮小、レンダリングの高速化、および整理が必要でした。
サイトは徐々に関連するハイパーテキストページのコレクションではなくなり、Webアプリケーションになりました。多くのサイトで以前に「メイン」ページと「内部」ページを作成するだけで十分だった場合、すべてがそれほど単純ではありません。設計レイアウトの数は数十から数百に達します。
ランディングページ、a / bテスト、「そのような」コンバージョンの複数の増加について聞いたことがあります。これらの手法の有効性の問題は残しておきます。デザインは頻繁にやり直され始めました-これは事実です。変更とサポートは、開発よりもはるかに高価で複雑であることが知られています。
モバイルデバイスとレスポンシブデザインの必要性が現れています。テストはますます難しくなりました。テスト中に見つかったバグを修正するサイクルが長くなりました。 UIテストを自動化することはほとんど不可能であり、機能の成長に伴い、回帰テストの時間は着実に増加しています。
バックエンドコードとの統合はより複雑になり、これをはるかに頻繁に行う必要があります。

これらすべてにより、フロントエンドでの作業の最適化について考えるようになります。

私が欲しい：

統合作業の時間と量を削減します（レイアウトをサーバーテクノロジーに「引き込む」）
html、css、jsの再利用を増やし、関連するコードの量を減らします
既存のコードを変更する時間を短縮
変更中のエラー、特にリグレッションを削減
レスポンシブデザインを効果的に作成および課す方法を学ぶ

最も簡単なソリューションは、サーバー側のテンプレートを完全に放棄し、REST-APIとSPAに切り替えることです

長所

統合フェーズは完全に消えます
背面と前面は分離されており、各チームはモバイル性が高く、共通のツールセットをまったく使用する必要はありません
フロントエンドワーカーはサーバースタックを展開する必要はありません

短所

SEO
「脂肪クライアント」の必要性
暗黙的なコードの複製：クライアント上のViewModelとサーバー上のDTO

短所はかなり深刻です。テンプレートがサーバー上にある場合のオプションは何ですか？

フロントローダーはサーバーテンプレートを編集します

長所

バックエンドを「プル」しないでください

短所

フロントエンドワーカーは、2つのツールセットを保持し、それらを切り替える必要があります
フロントランナーがなじみのない技術、あらゆる種類の@using（Hml.BeginForm（// ...および<？Php $ form-> textbox（ 'name'）を使用することは困難です。
フロントエンドワーカーはサーバーコードを解読でき、これを理解できない
フロントエンドワーカーがバックエンドコマンドのコーディング標準を知らない
フロントエンドワーカーは、アプリケーション全体をデプロイおよび構成する必要があります。 DBおよびその他の依存関係

フロントエンドエディタは、サーバーを挿入せずに（場合によってはプリプロセッサを使用して）純粋なhtmlでテンプレートを編集し、バックエンドに渡します。

長所

一連のツールを複製する必要はありません。誰もが自分のことをやっています。
簡単な環境設定
異なる請負業者による多くの完全に異なるレイアウトを同時にレイアウトする機能

短所

仕事の重複
2つの場所でテンプレートを編集する必要がある
統合コストを削減していません

フロントエンドワーカーは、レイアウトにサーバーエンジンを使用し、レイアウト、ブロック、テンプレートを個別に割り当てます

長所

統合コストは事実上なくなります
サーバーとクライアントで同じツールとプログラミング言語のセットが使用されます（このアプローチは、node.jsにとって特に魅力的です）
パターンとブロックの「カッティング」を調整するには、フロントコマンドとバックコマンド間のより緊密な相互作用が必要です。

短所

ツールが必要です。おそらく既に存在しているので、書く必要があります（phpとasp.netの場合、これは1〜2日で完了します）
ツールは、sass / less / stylus /その他のお気に入りのプリプロセッサと互換性がない場合があります
新入社員の急な学習曲線
テンプレート、ビューモデル、およびファイルシステム内のファイルの場所を作成するための、明確に規定された規制とスタイルガイドの必要性
パターンとブロックの「切り取り」を調整するには、フロントコマンドとバックコマンドの間のより緊密な相互作用が必要です（はい、これはプラスとマイナスの両方です）

説明したすべてのアプローチを試しました。私の経験では、プロジェクトの種類、セテリスパリバスに応じて、最初と最後のオプションが最適に機能します。

そして、BEMはどこにありますか？

おそらく、BEMは私たちの時代の最も全体的なトピックの1つなので、下の図を挿入することはできません。

。

私はBEMとセマンティックレイアウトで作業しようとしましたが、要件と変更を絶えず変更すると、頻繁にマークアップを変更し、CSSのタグ名とカスケードに結び付ける必要があるという結論に達しました-アイデアはまあまあです

カスケードが悪いのはなぜですか？

「カスケード」スタイルのページからカスケードを「スロー」するという考えは、一見すると皮肉に見えますが、

ほとんどのブラウザは右から左にスタイルを処理し、レンダリング速度の差.some-block .some-element li> p aと.some-block__linkは数回に達する可能性があり、これを考慮する必要があります。
カスケードを維持および変更することは非常に難しく、再利用可能なコンポーネントを作成することは困難です。

スタイルでのIDの拒否により、ビューの構成が排除されます

#some-element p, #some-other-element p, #one-more-fucking-id p, .what-the-hell-class-name p.is-doing-here{ /*…*/ }

「クラシック」CSSは、規則と規制を明確にすることを推奨していますが、指示していません。そのため、VasyaはFedyaの入力方法を好まない場合があります。 BEMには統一された方法論が含まれているため、VasyaとFedyaは、方法論に従ってすべてを同じように行います。これは、プロジェクトのバスファクターを増やし、目的のスタイルの検索時間を短縮するための良い方法です。
ブロック、要素、特に修飾子の概念は、画面のサイズに応じて異なる要素に異なるブロックを表示したり、異なる要素にブロック/要素を表示したりする場合のレスポンシブデザインに非常に適しています。
ブロック、要素、および修飾子は、異なる専門家間のコミュニケーションに適した用語です。「非技術者」がこれらの言葉を恐れず、同時に特定の技術に関連付けられるように、それらは十分に直感的です。

これらの事実により、BEMを考慮し、makeいクラス名に耐えることができます。ただし、BEMの作成者でさえも、BEMは方法論であり、プロジェクトとチームのニーズに合わせて「ドラフト」できると主張しています。このため、チームにはチェックリストが必要です。

私のチェックリスト

一般的な要件

メイクアップはクロスブラウザでなければならず、グリッド上で、デザインのインデントのエラーを修正することができます
レイアウトは、BEM方法論に従って実装する必要があります
レイアウトはw3c検証に合格する必要があります
このチェックリストの要件を満たすレイアウト
テーブルは表形式のデータを表すためにのみ使用する必要があり、ネストしたテーブルは許可されません

フォーム

フォームは常にformタグを使用してフォーマットする必要があります。タグにはaction属性が含まれている必要があります
ボタンは入力タグまたはボタンタグで装飾する必要があります
電話の場合、定型入力を使用する必要があります
検証を実装する必要があります。

BEM

以下の例外を除き、スタイルを設定するために要素IDとタグ名を使用することは禁止されています
クラスには、次の原則に従って名前を付ける必要があります。some-block__ some-element_ some-modificator
禁止されているインラインスタイル
ブロックと要素の名前は、それらの表示方法ではなく、目的と機能に対応する必要があります。

ブロックが異なる機能を実行するが、同じように見える場合、それらは類似性を反映するニュートラルな名前を持つ1つのブロックとして設計される必要があります。過度のコード重複なし
クラス名を持つことができないすべてのタグに対して正規化を使用する必要があります（以下にケースを説明します）。reset.cssの使用は許可されていません。 normalize.cssを使用することは受け入れられます。これは、正規化オプションがクラスを指定することが不可能なタグに対してのみであるように
次の状況を除き、複数の要素の深さを持つカスケードスタイル（たとえば、 テーブルtd ）を使用することは禁止されています。使用するブロック修飾子に応じて、子要素/ブロックを別々に表示する必要があります。カスケードは短く、java-script修飾子を動的に切り替えると、すべての子要素のスタイルを変更する場合よりも、DOMと対話するという点で実装がはるかに単純で効果的です。
ブロックの接頭辞b-は使用されません
グローバル修飾子は、たとえば_uppercaseのように、別個のクラスとして宣言する必要があります。先頭のアンダースコアは、ブロックではなく修飾子であることを示しています。アダプティブレイアウトの場合、特定のデバイスでのみ表示する必要があるブロックに対して、グローバル修飾子_desktop 、 _tabletおよび_phoneを使用する必要があります。モバイルファーストのアプローチを使用することをお勧めします。単純なものから複雑なものまで
要素クラスを制御できない場合は、親カスケードを介してスタイルをタグに適用する必要があります。次に例を示します。
- ユーザーがサイトのフォームからコンテンツを入力するか、動的に作成されるか、当社の管理下にない他のソースから取得します
- フォームコントロール：フォーム要素はサーバー側コードを使用して作成できるため、親カスケードが優先されます。要素のスタイルを保持するには、追加の再フォーマットが必要です。これは望ましくありません。

フォーマットとファイルシステム

1つの大きなCSSファイルまたはJSファイルの使用は受け入れられません。つまり、次のような分岐ファイル構造を使用する必要があります。
各ブロックは独自のフォルダーにあり、再利用可能なブロックとメインレイアウトは共有フォルダーにあります。
ブロックとすべての要素の説明は、 <BLOCK_NAME> .cssという単一のファイルにあります。ブロックと要素の説明が600行を超える場合は、分解する必要があります
クラス名とCSSルールはアルファベット順にソートされます
修飾子はスタイルの40％以下を再定義する必要があります。そうでない場合は、新しいブロックを作成することをお勧めします
ブロックHTMLテンプレートは同じフォルダーにあります（サーバーまたはクライアントテンプレートテクノロジーが使用されます）
レイアウトはページから分離され、必要なすべてのページは個別のファイルに「カット」されます

結束、縮小、組み立て

すべてのリソースは、本番用に準備し、バンドルに分割する必要があります。バンドルは、その数が最小になり、バンドルの重みが250KBを超えないようにグループ化する必要があります。
htmlレイアウトをレイアウト、ページ、ブロックに分割するためのサーバーテクノロジーの使用は許可され、推奨されています。
受け入れは「アセンブリ」の後に行われます。結果は、n個のhtmlページと、レイアウトされたすべてのページへのリンクを含むindex.htmlファイルです。「コレクター」のサイズが10 MBを超えず、ホストOSでの実行が保証されている場合、添付のbat / make-fileと「コレクター」を使用して、「ソース」でレイアウトを転送することができます。
cssおよびjsファイル内のリンクは絶対でなければなりません。そうしないと、縮小後に正しく機能しないリスクがあります。

優れたBEM材料の選択：

新入社員向けのすばらしい入門ガイド

この文書habrahabr.ru/post/114256の規模のため、チェックリストとして使用することは困難です。チェックリストとして機能する要約版は次のとおりです： github.com/delka/html5checklist

BEMチェック

 s=document.createElement('script');s.src ="//2gis.github.io/makeup/autoload/script.js";document.body.appendChild(s)

人間の顔とバックエンドの統合を備えたBEM