BEM pratique



Salutations. Dans cet article, je vais vous expliquer comment modifier BEM, conserver ses meilleures fonctionnalités et éliminer les pires.

Alors d'abord, parlons de ce qui ne va pas avec BEM? Peut-être que rien ne doit être changé et que tout va si bien?

BEM est une méthodologie qui vous permet d'utiliser plusieurs fois CSS / HTML / JS. Elle présente les concepts de bloc, élément, modificateur et mix. En commençant à l'utiliser, vous comprenez que c'est exactement ce que vous attendez depuis de nombreuses années, c'est tellement pratique, clair et beau! Mais après un certain temps, de tels moments de développement commencent à se produire qui peuvent être résolus avec BEM, mais cela n'apporte ni plaisir ni, plus important encore, avantages. De quoi je parle? Passons en revue ces points:

1. Blocs et articles jetables


Ce problème m'a tellement dérangé que j'ai été obligé d'écrire cet article.

Le concept de bloc implique une entité qui peut et doit être réutilisée, cependant, dans la pratique, un grand nombre de blocs sont créés et appliqués une seule fois.

Par exemple, nous devons faire ce qui suit: placer un en-tête sur la page, suivi d'un champ de texte et d'un bouton d'envoi, comme indiqué dans l'image:



Que ferons-nous selon BEM? Il existe plusieurs options:

  1. Créer un bloc de formulaire et ses éléments: titre, bouton, champ de texte
  2. Créez des blocs séparés pour chacun des composants (bouton, zone de texte, titre), ainsi que pour le formulaire
  3. ...

Quoi que nous choisissions, nous aurons un problème: comment définir l'indentation entre tous ces blocs?

Si nous avons choisi la première option, nous pouvons alors décider de mettre en retrait les éléments du formulaire, car cela ne contredit pas la méthodologie. Cependant, dans ce cas, nous détruisons l'essence du bloc: il ne peut pas être réutilisé, car son balisage interne ne s'adaptera qu'à la situation actuelle.

Si nous choisissions la deuxième option, il serait alors possible de mélanger un bloc à la forme, et les éléments de ce bloc à mélanger aux composants de la forme. Et, en conséquence, pour les éléments du bloc qui vient d'être créé, définissez l'indentation. Et ici, le problème des blocs à usage unique apparaît: ils sont créés pour être utilisés en un seul endroit! Ils ne peuvent plus être utilisés car les composants seront placés différemment sur d'autres pages.

Ce problème génère des blocs / éléments à ___size_ ___place_---- , ainsi que des modificateurs de type ___size_ ou ___place_---- (pour l'indentation), qui, comme cela a déjà été dit, sont utilisés une fois et encombrent les deux fichiers de balisage et le projet avec leurs propres répertoires et fichiers.

Il en va de même non seulement pour l'indentation, mais aussi pour les tailles de bloc (pour les boutons, par exemple, cela conduit souvent à un changement de line-height ), les tailles de police, l'indentation, etc.

2. Noms de classe longs


Il n'y a même pas grand-chose à dire. Je ne pense pas que quiconque aime le balisage qui ressemble à ceci:

 <header class="section-header section-header_margin_select-sector"> <h2 class="section-header__title font font_face_calibri-bold section-header__title_size_select-sectors"> Select a sector, please: </h2> </header> 

3. Valeurs par défaut ou thèmes de bloc


Supposons que nous ayons un bloc de boutons. Vous devez le styliser conformément aux exigences de conception. Mais dans un autre projet, il y aura également une classe de boutons. Cela aura l'air différent, mais certains styles seront les mêmes. Que recommande BEM? Il dit de créer un modificateur de thème et de le définir sur tous les éléments requis.

Mais avec cette approche, les résultats suivants se révéleront:

 <input type="text" class="textbox textbox_theme_P2"> <button class="button button_theme_P2">Reset</button> <button class="button button_theme_P2">Submit</button> <button class="button button_theme_P2">Save as draft</button> 

C'est un encombrement de code, et c'est mauvais.

Vous critiquez - offrez


Qu'est-ce que je propose pour corriger cette honte? Je propose le manifeste suivant, qui est essentiellement un complément au BEM standard.

Manifeste - BEM amélioré


A.1 Couche de modules et couche de page


Je propose de diviser le style en deux parties:

La première partie est la couche des composants. Cette partie est écrite conformément à toutes (presque *) les règles BEM. Il définit les styles des blocs réutilisables, ou plutôt des composants, par exemple, pour un bouton, un champ de texte, un titre, etc.

L'autre partie est le calque de page. Il est nécessaire de définir les styles de blocs et d'éléments d'une page particulière. En conséquence, ces blocs / éléments ne seront utilisés qu'une seule fois (dans tous les cas, sur une seule page). Les règles BEM ne s'appliquent pas ici. Cela ressemble à ceci:

Fichier: index.css

 .___send-button { margin-bottom: 2px; font-size: 13px; } .___message-textarea { width: 240px; height: 300px; font-size: 14px; } 

Le nom du fichier de mise en page est facultatif. L'essentiel est qu'il corresponde à l'essence de la page. Tous les styles commencent par '___' afin qu'ils ne puissent pas être confondus avec les classes d'entités BEM standard. De plus, les classes ne sont pas liées aux entités BEM - leurs noms reflètent uniquement ce à quoi elles doivent être appliquées. Il convient également de noter que tous les styles de la mise en page se trouvent dans un seul fichier, car ils concernent une seule page.

Cette séparation nous permet de résoudre le premier problème, sans préjudice de l'objectif principal de BEM - créer des styles / balisages afin qu'ils puissent être réutilisés. Ces styles seront appliqués sur une seule page et n'interféreront en aucun cas avec les styles de composants de la disposition des composants. Ainsi, nous nous débarrassons des classes à usage unique, tout en conservant la possibilité de réutiliser des blocs et sans violer la portée.

Il est également judicieux de séparer les composants et les mises en page au niveau du répertoire.

* à l'exception des règles annulées par les paragraphes suivants du manifeste.

A.2 Noms de classe longs


(Expérimental, donc optionnel *)

Il est proposé de remplacer une partie du système de dénomination standard par ce qui suit:

Pour le bloc: class="" (aucun changement)
Pour un bloc avec un modificateur: class=" _" (accès via le sélecteur combiné. .._ )
Pour un élément: class="__" (pas de changement)
Pour un élément avec un modificateur: class="__ _" (accès via .__._ )

Cet élément vous permet d'obtenir un code court concernant les modificateurs. Évidemment, la même chose ne peut pas être faite avec des éléments.

Il est important que les fichiers avec des styles n'aient pas de règles définies pour les sélecteurs qui se composent uniquement de modificateurs:

 /*!!!*/ ._active { background-color: #abcdef; } 

* une dénomination similaire des modificateurs peut entraîner des problèmes sur les blocs / éléments mélangés avec d'autres blocs / éléments, à condition que les deux entités puissent avoir le même modificateur. Autrement dit, en définissant un modificateur pour une entité, nous le définissons pour tous ceux qui sont mélangés à ce nœud.

A.3 Valeurs par défaut et thèmes


Ici, tout est simple. Il est proposé de choisir un thème par défaut, mais de lui prescrire des styles non pas dans la classe de bloc qui se trouve dans le fichier de bloc, mais dans la classe de bloc qui doit être placée dans le fichier de thème. Par exemple:

Fichier - button/button.css

 .button { cursor: pointer; display: inline-block; } 

Fichier - button/_theme/button_theme_P2.css

 .button_theme_P2, .button { border-radius: 3px; border: 1px solid #f00; } 

Ou conformément au paragraphe 2

 .button._theme_P2, .button { border-radius: 3px; border: 1px solid #f00; } 

Ainsi, ce sujet devient standard, mais vous pouvez l'utiliser directement si vous le souhaitez.



Résumé


Ce manifeste est conçu pour résoudre certains des problèmes qui surviennent lors de la mise en page conformément à BEM. Son composant principal était une décomposition en disposition des composants et mise en page. Bien que le manifeste semble assez révolutionnaire, peu canonique et audacieux, il résout les problèmes énoncés. Pour tout utiliser, partiellement ou ne pas l'utiliser du tout - bien sûr, vous décidez.

PS Si vous faites maintenant défiler avec colère toute la page pour mettre un moins, n'oubliez pas d'écrire un commentaire, sinon votre moins n'apportera aucun avantage ( ainsi que le manifeste ).

Source: https://habr.com/ru/post/fr440554/


All Articles