CSSガイドライン、パート3.クラスの命名

CSSの命名規則により、強力でクリーンで美しいコードを作成できます。 命名規則に従って、あなたは常に知っているでしょう：

• クラスは何に使用されますか？
• クラスを使用できる場所。
• このクラスに関連付けられている他のクラス。

従う命名規則は非常に単純です。セパレータとしてハイフンを使用し、複雑な場所ではBEMのような命名を使用します。



CSSを作成する場合、命名規則だけではあまりメリットがないことに注意してください。 マークアップを表示する際に非常に便利です。

ハイフネーション

クラス名のすべての単語は、ハイフンで区切る必要があります。

.page-head {} .sub-content {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CamelCaseとアンダースコアはクラスには使用されません。次の例は正しくありません。

 .pageHead {} .sub_content {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

BEMのような命名規則

インターフェイスのより大きな相互接続された部分には、BEMに似たクラス命名を使用します。



BEM、つまりBlock、Element、Modifierは、Yandex開発者によって作成された方法論です。 BEMはかなり大きな方法論であるという事実にもかかわらず、現時点では、要素の命名方法にのみ関心があります。 さらに、私の命名規則は元のBEMとは少し異なります。原則は同じですが、構文は異なります。



BEMは、レイアウトコンポーネントを3つのグループに分けます。

• ブロック：メインルート要素。
• 要素：ブロックの一部。
• 修飾子：オプションまたはブロックの変更。

アナロジーを描きましょう：

 .person {} .person__head {} .person--tall {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスの先頭に、ブロックの名前が常に置かれます。要素を指定するために、2つのアンダースコア（__）で要素の名前からブロックの名前を分離し、2つのハイフン（-）を使用する修飾子を示します。



上記の例では、 .person {}



がブロックであることがわかります。 彼には先祖がいません。 .person__head {}



はブロックの一部である要素です。 最後に、 .person--tall



は修飾子、一種の.person {}



ブロックです。

ブロックを使用する

ブロックは論理的な独立したユニットでなければなりません。 クラス.person {}



を使用して例を続けます.room {}



は別のユニットであるため、クラス.room__person



作成できません。 この場合、ブロックを分ける価値があります：

 .room {} .room__door {} .room--kitchen {} .person {} .person__head {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

部屋の中の人を特定する必要がある場合、そのようなセレクター.room .person



を使用する方がより適切.room .person



。これにより、さまざまな不明瞭な要素やブロックの山からポリッジを作成できなくなります。



ブロックの正しい使用のより現実的な例は、次のようになります。

 .page {} .content {} .sub-content {} .footer {} .footer__copyright {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードの各部分は、独自のブロックを表します。 誤った使用例：

 .page {} .page__content {} .page__sub-content {} .page__footer {} .page__copyright {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

BEMを使用する価値がある場所とそうでない場所を区別できることが重要です。 通常、ブロックを使用して、ユーザーインターフェイスの自律的な部分を記述します。

多くの層

.person {}



ブロックにもう1つの要素、たとえば.person__eye



追加した場合、前の要素の名前をルート要素まで追加して、要素に名前を付ける際に一歩戻る必要はありません。 つまり、 .person__eye



ではなく、 .person__eye



書き込みます。

アイテムの変更を追加する

要素のバリエーションを追加する必要がある場合があります。これは、これらの要素を変更する方法と理由に応じて、いくつかの方法で実行できます。 繰り返しますが、人の目が青い場合、CSSでは次のように記述できます。

 .person__eye--blue {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、実際のプロジェクトでは、事態はもう少し複雑です。 私はそのようなアナロジーをおpoびしますが、美しい顔をした男を想像してみましょう。 それ自体はあまり美しくないので、最良の解決策は.person__face {}



要素に修飾子を追加することです。

 .person__face--handsome {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、ハンサムな男性の顔を説明したい場合はどうでしょうか？ つまり、前の例とは異なり、人は自分自身で美しいので、顔を説明する必要がありますか？ これは次のように行われます。

 .person--handsome .person__face {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ブロックの変更に応じて要素を変更できる数少ないケースの1つです。 Sassを使用する場合、次のコードがあります。

 .person {} .person__face { .person--handsome & {} } .person--handsome {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.person__face



要素の中に新しい.person__face



要素を追加していないことに注意してください.person--handsome



; 代わりに、既存の.person__face



セレクター内で親Sassセレクターを使用します。 これは、 .person__face



関連付けられているすべてのルールが1つの場所にあることを意味し、ファイル全体にそれらを分散させる必要はありません。 これは、ネストされたコードを操作する場合の良い習慣です。必要なすべてのスタイルを同じコンテキスト内に.person__face



ます（この場合、 .person__face



内）。

マークアップの命名

前述したように、クラスの命名規則はマークアップを使用する場合に最も役立ちます。 契約に従わずに、次のマークアップをご覧ください。

 <div class="box profile pro-user"> <img class="avatar image" /> <p class="bio">...</p> </div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.profile



クラスと.profile



クラスは相互にどのように関係していますか？ .profile



.avatar



と.avatar



は相互にどのように関連していますか？ それらはまったく接続されていますか？ .bio



クラスは.pro-user



クラスに.bio



していますか？ このマークアップの外で.avatar



クラスを使用することは可能ですか？



このようなマークアップを表示するとき、これらのすべての質問に答えることは非常に困難です。 命名規則を使用すると、次のことが変わります。

 <div class="box profile profile--is-pro-user"> <img class="avatar profile__image" /> <p class="profile__bio">...</p> </div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、どのクラスが相互に関連しているか、どのクラスがどのように関連しているか、すぐにわかります。 このマークアップ以外では使用できないクラスを知っています。 最後に、どのクラスでも他のどこでも使用できることがわかります。

Javascriptフック

原則として、JSとCSSコードをマークアップ内の同じクラスにバインドするのは不合理です。たとえば、1つのクラスを削除または変更してスクリプトの動作を変更すると、CSSに確実に影響し、その逆も同様です。 JSを個々のクラスにバインドする方がはるかにクリーンで、透明性が高く、一般的に優れています。



スタイルを処理する目的で一部のクラスを削除すると、ページ上のすべてのスクリプトの作業が中断され、すべての開発者がスクリプトを使用してスタイルを同じクラスに関連付けなかったため、ケースに遭遇しました。



原則として、開発者は接頭辞「js-」で始まるjsの別のクラスを使用します。次に例を示します。

 <input type="submit" class="btn js-btn" value="Follow" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このマークアップにより、 .js-btn



動作に影響を与えることなく、 .btn



スタイルを使用できます。

data- *属性

また、非常に頻繁に、開発者はdata-属性をjsフックとして使用しますが、これは正しくありません。 data- *属性は、仕様に従って、ページで使用できないデータを格納するように設計されています。 data- *属性は、jsにバインドするのではなく、データを保存するように設計されています。

テーマの継続...

すでに述べたように、上記のすべてのルールは非常に単純です。 このトピックに関する他の資料を読んだり、学んだことを考えないでください。これにより、クラスに名前を付ける機会を増やすことができます。

さらなる研究のための資料

• めまいがするBEMへの没入 （ 翻訳があります ）

前のパート： CSSガイドライン、パート2。コードについてのコメント