[英国] BEM を使用して CSS コードをモジュール化する_html/css

BEM を使用して CSS をモジュール化する方法

BEM に詳しくない方のために説明しておくと、BEM はかなり厳密な命名方法を提供します。 CSS クラスを独立したコンポーネントに配置する方法。これは Block Element Modifier の略で、一般的なものは次のようになります:

.block {}

ログイン後にコピー

.block__element {}

ログイン後にコピー

.block--modifier {}

ログイン後にコピー

.block__element--modifier {}

ログイン後にコピー

原理は単純です — Block はオブジェクト (a 要素は、特定の機能 (手、ログインボタン、メニュー項目) と 修飾子 を実行するブロック内のコンポーネントです。これは、ブロックまたは要素のバリエーション (女性、ラベルが非表示になった凝縮されたログインフォーム、フッターのコンテキストで異なって見えるように変更されたメニュー) を表現する方法です。

方法論を詳しく説明したリソースがオンラインにたくさんあります ( https://css-tricks.com/bem-101/ 、 http://getbem.com/naming/ )。この記事では、プロジェクトにそれを実装する際に直面した課題について説明することに焦点を当てます。

スタイルを移植し、Block-Element-Modifier 手法を使用することを決定する前に、すべては少しのリサーチから始まりました。周りを見回すと、考えられるすべての質問に答えてくれそうな記事、リソース、ミックスイン、ドキュメントが数十件見つかりました。私たちが新しい親友を見つけたのは明らかでした。

しかし、スケールに合わせて何かを構築することに深く入ると、かなり混乱します。そして、それと戦ってなんとかしようとすればするほど、それを見ずに友達として扱わない限り、状況は悪化します。私たちの物語は、数か月前に BEM と出会ったときに始まります。私たちは外に出て自己紹介をし、それから小さな街角のプロジェクトに一緒に取り組むよう誘いました。私たちのつながりは良好だったので、この決断に至りました。私たちはそれが気に入っており、この友情を次のレベルに引き上げたいと考えています。

私たちが従ったプロセスは比較的単純で、どういうわけか自然でした。私たちは命名規則を実験し、スタイルシートクラスを手動で作成しました。一連のガイドラインを決定した後、新しいモディファイアや要素を追加するたびにブロック名を渡す必要がなく、クラス名を生成する基本的なミックスインを作成しました。

それで、私たちの旅は次のようなものから始まりました:

その後、カスタムミックスインのセットを使用して、上記を次のように変換しました:

そして、徐々に、どんどん増えていきます。エッジケースが出現し始めたため、既存のコードを変更することなくミックスインを改善しました。

たとえば、フルサイズの修飾子のコンテキストでリスト要素を定義したい場合は、次のようにします:

裏庭で BEM を行う方法

私たちは、いきなりこの方法論に従うようにすべてを変換したわけではありません。私たちは徐々にそれを進め、パターンが見えるまで散在的なピースから始めました。

他の関係と同様、物事をうまく機能させるには双方の理解が必要です。私たちが従うガイドラインの一部は方法論の一部であり、私たちは疑問を持ちません。また、一部は将来的に私たち自身で追加したものです。

私たちにとっての基本ルールは次のとおりです。ブロックの中にブロックをネストしたり、要素の中に要素をネストしたりすることはありません。これは私たちが絶対に破ってはいけないと定めた唯一のルールです。

単一ブロックのネストの最も深いレベルは次のとおりです。

さらにネストする必要がある場合は、複雑さが多すぎるため、要素をより小さなブロックに分割する必要があることを意味します。

ここでのもう 1 つのルールは、要素をブロックに変換する方法にあります。ルール#1 に従って、すべてをより小さな懸念事項に分割します。

それで、対応コンポーネントに次の構造があるとします。

まず、上位の構造を作成します。 -レベルブロック:

次に、より小さい内部構造に対してプロセスを繰り返します:

タイトルがより複雑になった場合は、それをさらに別の小さな懸念に抽出します:

そして、さらに複雑さを加えます。アクションをホバー時に表示したいとします:

すべてが完了した後、コードをスタイルシートに戻すと、次のようにきれいにレイアウトされます。 :

そして、不必要なセマンティクスの一部をクリーンアップすることを妨げるものは何もありません。私たちの項目は明らかにリストの一部であり、通信のコンテキストには他の項目がないため、その名前を 通信項目 に変更できます:

これは私たちが使用する別のガイドラインです —他のブロックと競合しない場合は、ネストされたコンポーネントの BEM ブロックの命名を簡素化します。

たとえば、実際にはメインブロックに対応タイトルを設定したり、プレビュー内にタイトルを設定したりできるため、項目タイトルにはこれを行いません。それはあまりにも一般的すぎます。

ミックスイン

上で使用しているミックスインは、内部スタイルライブラリであるペイントの一部です。

これらはここで見つけることができます: https://github.com/alphasights /paint/blob/develop/globals/functions/_bem.scss

ペイントは bower/NPM パッケージとして利用可能であり、コアの再設計が行われています。 BEM ミックスインは今でも使用でき、定期的にメンテナンスされています。

そもそもなぜミックスインが必要なのでしょうか?

私たちの目的は、前から知っていたように、CSS クラス生成システムを非常にシンプルにすることでした。エンドおよびバックエンドの開発者は、スタイルシートの構築に多くの時間を費やす必要がありません。そのため、可能な限りプロセスを自動化しました。

現時点では、テンプレートに対して同じことを行うヘルパーコンポーネントのセットを開発中です。これは、ブロック、要素、および修飾子を定義する方法を提供します。次に、 CSS の場合と同様に、マークアップクラスを自動的に生成します。

仕組み

処理を容易にするためにセレクターを文字列に変換する関数 _bem-selector-to-string があります。 Sass (レール) と LibSass (ノード) ではセレクター文字列の処理が異なるようです。クラス名のドットが文字列に追加される場合があるため、予防措置として、以降の処理の前に必ずそれを削除するようにします。

セレクターに修飾子があるかどうかを確認するために使用する関数は _bem-selector-has-modifier です。修飾子セパレーターが見つかった場合、またはセレクターに疑似セレクター (:hover、:first-child など) が含まれている場合、true を返します。

最後の関数は、修飾子または疑似セレクターを含む文字列からブロック名を取得します。 _bem-get-block-name は、 対応 — フルサイズ が渡された場合、対応を返します。モディファイア内の要素を操作するときはブロック名が必要です。そうでないと、適切なクラス名を生成するのが困難になります。

bem-block ミックスインは、ブロック名と渡されたプロパティを持つ基本クラスを生成します。

bem-modifier ミックスインは、 .block — modifier クラス名を作成します。

bem-element ミックスインはもう少し機能します。親セレクターがモディファイアであるかどうか (または疑似セレクターが含まれているかどうか) をチェックします。存在する場合、 ブロック、つまり内部に block__element を持つ修飾子 を含むネストされた構造が生成されます。それ以外の場合は、 block__element を直接作成します。

要素と修飾子については、現在 $elements 内の @each $element を使用していますが、次のバージョンではこれを最適化し、各要素でプロパティを複製するのではなく、同じプロパティを共有できるようにする予定です。