J'ai écrit cet article dans le but de répondre à des questions sur BEM qui ne sont généralement pas posées, mais le manque de réponses impacte le développement et la compréhension de l'architecture.
Cet article ne s'adresse pas aux débutants qui apprennent TRÈS bien le CSS maintenant et/ou qui n'ont jamais eu de contact avec les conventions de dénomination des classes CSS. Si tel est votre cas, passez à la section sources.
En-tête adapté de l'ancien site Web officiel BEM CSS
Comme les plantes, la façon dont un code grandit et prospère dépend de la façon dont nous le créons, le maintenons et de l'endroit où les choses se trouvent.
Il existe des plantes avec des besoins différents en matière de sol, de traitement, d'eau et de lumière solaire, tout comme il existe des codes avec des besoins différents en matière de normes, d'emplacement et de gestion.
CSS est un élément essentiel dans le chargement des pages - le processus de rendu ne démarre pas avant que le navigateur demande, télécharge et transforme tous les HTML et CSS en DOM et CSSOM et assemble l'arbre de rendu. Moins il y a de CSS, meilleures sont les performances, plus le CSS est organisé, standardisé et robuste, mieux il est à maintenir, gérer, mettre à l'échelle et compresser.
La façon dont les sélecteurs CSS sont nommés influence la portée des règles, leur spécificité, leur emplacement et leur sémantique, accélérant ou détériorant le processus de développement. Dans les projets où plus d'une personne écrit du CSS, nous avons différents niveaux de compétence dans le langage et différentes coutumes ou normes personnelles, qui, si elles ne sont pas gérées, peuvent entraîner une répétition excessive des règles et des bugs.
BEM est une architecture CSS axée sur le styleguide, elle définit des standards de catégorisation et d'écriture de règles CSS. BEM a été créé chez Yandex dans un contexte d'applications contenant plusieurs pages gérées par une ou quelques feuilles de style.
BEM est l'acronyme de Block, Element, Modifier. Chacune de ces entités représente une catégorie d'élément d'interface, qui est directement représentée en CSS.
Un bloc représente un élément d'interface utilisateur qui est indépendant, il peut avoir des enfants, comme un en-tête a ses liens de navigation et ces enfants, s'ils sont indépendants, peuvent aussi être des blocs.
La notion d'indépendance d'un composant d'interface peut être définie par l'axiome suivant
"Si le composant n'a de sens que dans un contexte précis, il doit être un élément de ce contexte. S'il peut exister dans plusieurs contextes, il doit s'agir d'un bloc indépendant."
Un élément est un composant qui en constitue un autre plus grand et qui lui appartient. Si ce composant n'existe pas et ne dépend pas uniquement du contexte dans lequel il est appliqué, il peut s'agir d'un bloc. Dans BEM, les blocs peuvent contenir d'autres blocs, si un élément doit contenir un élément, c'est probablement aussi un bloc.
La relation entre un bloc et un élément est représentée par le double trait de soulignement block__element.
Les blocs et les éléments peuvent contenir des variations esthétiques ou de disposition dans le même contexte. Pour cela nous avons des modificateurs. Ces classes peuvent représenter différents états ou variantes d'un même composant. Les modificateurs tels que les éléments dépendent du bloc et en dérivent uniquement.
La relation entre un bloc ou un élément et ses modificateurs est représentée par le double tiret block--modifier ou block__element--modifier.
| Referência | Descrição |
|---|---|
 |
Um checkbox é independente, pode ser aplicado dentro de outros componentes como |
 |
Uma label pode ser considerada um bloco independente se ela for igualmente aplicada nos inputs da aplicação. Se a diferença entre labels for estética, ela pode ser um bloco que contém diversas variantes (modifiers), se a diferença entre as labels do input for estrutural (no template), faz sentido ela ser o elemento de um bloco |
 |
Um card pode ser incluído em qualquer container, em diferentes contextos, podendo ser considerado independente (block). Se a imagem e textos dentro dos cards tiverem características que só faz sentido no contexto do card, elas podem ser consideradas elements |
 |
Um botão pode ser administrado em qualquer lugar, inclusive mais de uma variante no mesmo lugar. Cada variante pode ser representada pela classe modificadora derivada do mesmo bloco ou elemento. |
En utilisant l'exemple de checkbox, la façon dont nous construisons les composants et définissons leurs responsabilités influence ce qui peut être un bloc, un élément ou un modificateur. Cette prise de décision commence par le modèle :
<div class="form-field">
<input
class="form-field__input form-field__input--checkbox"
type="checkbox"
value=""
id="checkbox"
/>
<label class="form-field__label" for="checkbox">
Default checkbox
</label>
</div>
Dans ce modèle, nous avons le composant .form-field sous forme de bloc, qui contiendra toujours une entrée .form-field__input et une étiquette de classe .form-field__label. La relation entre le bloc (.form-field) et l'élément (label ou input) est exprimée par un double soulignement. Cette écriture signifie qu'à travers CSS nous comprenons que :
form-field est une entité indépendante, il ne dépend pas du contexte du composant ou du conteneur parent pour que ses styles fonctionnent, n'importe quel formulaire peut recevoir des champs de type .form-field
À son tour, le champ de formulaire peut contenir un __input et un __label, et sa disposition et son apparence dépendent du conteneur du champ de formulaire
.form-field {}
.form-field__input {}
.form-field__input--checkbox {}
.form-field__label {}
Lorsque nous modifions la relation dans le modèle, nous modifions la topographie de la classe CSS. Dans l'exemple ci-dessous, input et label sont des entités distinctes :
<div class="column">
<label class="label" for="checkbox">
Default checkbox
</label>
<input
class="input input--checkbox"
type="checkbox"
value=""
id="checkbox"
/>
</div>
Exprimé en CSS, cela ressemblerait à ceci :
.column {}
.input {}
.input--checkbox {}
.input--checkbox:checked {}
.label {}
BEM se concentre sur l'indépendance des composants - la modification de l'emplacement d'un composant dans le HTML ne devrait pas affecter sa mise en page, la modification du CSS d'un composant ne devrait pas affecter les autres composants. Lorsque nous créons des éléments, nous démontrons une liste de ce qui sera affecté lorsque nous modifierons leur bloc. De cette façon vous avez une visibilité sur ce que serait un composant couplé à ses parties et un module complètement indépendant. Comme cité dans la documentation existante :
En 2006, nous avons commencé à travailler sur nos premiers grands projets : Yandex.Music et Ya.Ru. Ces projets, comptant des dizaines de pages, ont révélé les principaux inconvénients de l'approche actuelle du développement :
- Toute modification apportée au code d'une page affectait le code des autres pages.
- C'était difficile de choisir les noms de classe.
En 2006, nous avons commencé à travailler sur notre premier grand projet : Yandex.Music et Ya.Ru. Ces projets qui comptaient des dizaines de pages se sont révélés être les inconvénients de l'approche de développement actuelle :Traduction
En 2010, lorsque BEM est devenu open source et s'est doté d'un site Web, l'idée selon laquelle chaque élément de l'interface utilisateur était un « composant » était déjà présente, avant même la conception atomique (Brad Frost, 2013) en réponse au défi de maintenir la cohérence des les mêmes composants sur des pages différentes. Lorsque BEM a été créé chez Yandex, par exemple, ils utilisaient plusieurs fichiers HTML et un seul fichier CSS et un fichier Javascript.
Si chaque page était un bloc et que ses éléments dépendaient du contexte de cette page, tout le code cohérent entre les pages serait dupliqué. La séparation de l'interface utilisateur en petits composants a permis la réutilisation de ces parties quelles que soient les pages sur lesquelles elles étaient utilisées.
Pour illustrer ce concept de réutilisation, nous pouvons utiliser un composant plus complexe, comme un en-tête :
Cet en-tête peut s'écrire comme suit (HTML court) :
<nav class="navbar">
<div class="navbar__container">
<a class="navbar__logo" href="#">Navbar</a>
<button class="navbar__toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
<span class="navbar__toggler-icon"></span>
</button>
<div class="navbar__collapse" id="navbarSupportedContent">
<ul class="navbar__list">
<li class="navbar__item">
<a class="navbar__link active" aria-current="page" href="#">Home</a>
</li>
<!-- etc -->
<li class="navbar__item navbar__dropdown">
<a class="navbar__dropdown-toggle" href="#" role="button" data-bs-toggle="dropdown" aria-expanded="false">
Dropdown
</a>
<ul class="navbar__dropdown-menu">
<li>
<a class="navbar__dropdown-item" href="#">
Action
</a>
</li>
<!-- etc -->
</ul>
</li>
<!-- etc -->
</ul>
<form class="navbar__form" role="search">
<input class="navbar__form-input" type="search" placeholder="Search" aria-label="Search">
<button class="navbar__form-btn" type="submit">
Search
</button>
</form>
</div>
</div>
</nav>
Remarquez que dans cet exemple, la barre de navigation entière a été déclarée comme un seul gros bloc et que tout ce qu'elle contenait a été considéré comme un élément de la barre de navigation. En conséquence, nous perdons plusieurs opportunités de réutilisation.
| Oportunidade | Descrição |
|---|---|
 |
O logotipo dentro de .navbar__logo é representado por um link contendo imagem ou texto. Existem diversos elementos que podem ser 'envelopados' em um link, como ícones back to top ou cards clicáveis. Esse código poderia pertencer a um bloco .link ou .media |
 |
Os itens .navbar__list e .navbar__item nada mais são que uma lista desordenada no formato de linha ao invés de coluna. Isso poderia reutilizado representando-a pelo bloco .list com o modificador .list--row. O dropdown por sua vez pode ter o mesmo funcionamento fora do navbar, dentro do seu próprio bloco .dropdown, com seus elementos .dropdown__toggle e, como ele renderiza uma lista, podemos reutilizar .list e, se necessário, complementar com um modificador |
 |
Esse componente de busca pode ser representado de forma mais "fechada" com um bloco .search e elementos .search__input, search__label e .search__trigger ou de forma mais "aberta" como .form-field, .input--text, .label e .button--outline |
Ainda pensando nessa relação de componentes "abertos" e "fechados", podemos representar o componente de busca usado no último exemplo das duas forma usando CSS.
Componente de busca "fechado"
Os elementos input, label e button são acoplados ao bloco search, mudanças no componente ou no HTML de search influenciam nos seus elementos.
.search {}
.search__input {}
.search__label {}
.search__button {}
Componente de busca "aberto"
Os elementos input, label e button são independentes do bloco de search, ele apenas organiza os blocos já existentes que compõe esse componente.
.form-field {}
.input {}
.input--text {}
.label {}
.button {}
.button--outline {}
Um dos problemas citados pela galera do Yandex é que mudanças no CSS podiam afetar partes indesejadas. No caso deles era utilizada uma folha de estilo pra todas as páginas da aplicação, e você pode achar que não é um problema pra ti se você usa algum processador como Sass ou diversos arquivos de CSS, mas é uma dor de cabeça ainda maior quando seletores de diferentes abrangências moram em múltiplos arquivos.
A forma que o BEM encontrou de contornar esse problema além da modularização de blocos é a especificidade. BEM só utiliza classes por motivos bem claros:
Abaixo vemos um accordion que mantém uma diversidade de seletores, pra nos referirmos, por exemplo ao h2 desse accordion, temos que explicitamente dizer #accordion-item > h2:
<div id="accordion-item">
<h2>
<button class="btn">
Accordion Item #1
</button>
</h2>
<div class="collapse show">
<div>
<strong>This is the first item's accordion body.</strong>
</div>
</div>
</div>
Pra estilizar todos os elementos desse componente, precisamos estabelecer as seguintes relações:
/* 1,0,0 */
#accordion-item {}
/* 1,0,1 */
#accordion-item > h2 {}
/* 1,1,0 */
#accordion-item .btn {}
/* 1,1,0 */
#accordion-item .collapse {}
/* 1,2,0 */
#accordion-item > .collapse.show {}
/* 1,1,1 */
#accordion-item > .collapse > div {}
/* 1,1,2 */
#accordion-item > .collapse strong {}
Esse exemplo assume que .collapse por não se referir diretamente ao accordion (não é um .accordion-collapse, por exemplo) pode existir em outros lugares do código ou até em outros lugares de #accordion-item. Isso obriga a gente a deixar explícita sua relação com #accordion-item.
A regra #accordion-item > .collapse > div existe pois o estilo não pode impactar qualquer div, nem qualquer .collapse, pra alterar apenas aquilo que existe dentro do bloco #accordion-item precisamos adicionar muito mais complexidade e especificidade, além de que qualquer mudança no HTML desse componente causa bugs imprevisíveis.
<div class="accordion-item">
<h2 class="title">
<button class="button">
Accordion Item #1
</button>
</h2>
<div class="accordion-item__collapse">
<div class="accordion-item__wrapper">
<strong>This is the first item's accordion body.</strong>
</div>
</div>
</div>
No HTML acima estabelecemos as relações entre o .accordion-item e o .accordion-item__collapse sem adicionar especificidade. Ao nos referirmos diretamente aos elementos pela classe e não compondo seletores, quando alteramos o .accordion-item podemos quebrar o .accordion-item__collapse, mas ao alterar .accordion-item__collapse, o .accordion-item dificilmente será influenciado.
.title e .button serem blocos independentes faz com que alterarmos o HTML desse componente ou o CSS dessas classes não cause nenhum bug, pois elas existem de forma independente do bloco do accordion. Em relação à especificidade, a relação passa a ser da seguinte forma:
/* 0,1,0 */
.accordion-item {}
/* 0,1,0 */
.accordion-item__collapse {}
/* 0,1,0 */
.accordion-item__wrapper {}
/* 0,1,0 */
.title {}
/* 0,1,0 */
.button {}
A especificidade dessas regras é muito mais previsível, tanto que se eu quiser adicionar uma variante ao .accordion-item__wrapper basta eu criar uma classe com as regras e incluir no elemento no HTML, sem precisar criar no CSS um seletor .accordion-item__wrapper.accordion-item__wrapper--vertical.
Quando me refiro a reuso de CSS, não falo apenas de blocos que podem ser reaplicados em diferentes componentes, à nível de seletores, mas também à conjuntos de regras que realizam as mesmas ações. No exemplo abaixo, temos 3 componentes diferentes e mesmo se escritos na convenção do BEM haverá repetição de conjuntos de regras:
| Elemento | Regras |
|---|---|
 |
.alert {
display: flex;
gap: 0.5rem;
/* etc... */
}
Copier après la connexion |
 |
.nav {
display: flex;
gap: 1rem;
/* etc... */
}
Copier après la connexion |
 |
.breadcrumb {
display: flex;
gap: 0.5rem;
/* etc... */
}
Copier après la connexion |
Percebe como todos os elementos que tem a disposição de 'linha' muito provavelmente terão um grupo de regras de display: flex o configura dessa forma, terão um gap: npx e provavelmente um flex-wrap: wrap quando fizer sentido pro layout 'quebrar' pra linha de baixo?
Usando o breadcrumb como exemplo, podemos criar um bloco que represente uma linha ou coluna genérica e que seja configurável à partir de variantes.
<ol class="breadcrumb"> <li class="breadcrumb__item">Home</li> <li class="breadcrumb__item active">Library</li> </ol>
Ao invés de repetir o conjunto de regras que configura uma coluna, podemos adicionar à classe .breadcrumb o bloco de .row. Não há restrições sobre o mesmo elemento ser representado por dois blocos distintos, pois o conceito de bloco é acoplado com seus elementos, não com componentes específicos.
/* Breadcrumb deixa de configurar o layout e passa apenas a implementar estilos estéticos */
.breadcrumb {
font: 200 1rem Poppins;
line-height: 1.45;
}
/* Row se torna responsável pelo layout */
.row {
display: flex;
gap: 1rem;
}
/* E pode ter variantes na convenção BEM caso conveniente */
.row--flexible {
flex-wrap: wrap;
}
Nesse caso o gap de .row é estático, mas os elementos apresentados nos exemplos tem diferentes valores nessa propriedade, de quem é a responsabilidade? Se você possuí uma estrutura de CSS utilitário, a responsabilidade pode ser de .row que será configurada pelo CSS utilitário .gap-0.5 ou .gap-sm.
Se você não usa CSS utilitário, o gap pode ser configurado pelo próprio componente breadcrumb:
/* Ao implementar o gap com variáveis CSS temos um valor
default e um valor configurável */
.row {
--row__gap-default: 1rem;
display: flex;
gap: var(--row__gap, var(--row__gap-default));
}
/* Dessa forma podemos configurar o gap pelo breadcrumb.
A row ainda não depende dele, mas caso ele seja aplicado com
uma row, ele a configura */
.breadcrumb {
--row__gap: 0.5rem;
font: 200 1rem Poppins;
line-height: 1.45;
}
Separar os estilos de layout dos de aparência é uma prática do OOCSS (link do artigo na Smashing Magazine, em inglês). Categorizar o CSS em skin e structure vem do entendimento de que a estrutura e layout de um elemento ou componente é mais reaproveitável e ubíqua do que a aparência de um componente.
Usando a convenção BEM é possível criar blocos que se referem à estruturas e modificadores que se referem à aparência, sendo ela apenas uma convenção de escrita de classes, a categorização e separação dessas classes pode ficar na responsabilidade de outro tipo de arquitetura.
Sass foi criado em 2009, um ano antes de BEM se tornar open source, a interação entre eles funciona extremamente bem (rsrs) por dois motivos:
.search {
&__input {}
&__label {}
&__button {}
}
Com CSS a relação de blocos e elementos se dá pelo prefixo do bloco, ex: .search__, no Sass os elementos são declarados dentro do bloco.
Um problema muito comum com Sass é o 'overnesting', que é quando aninhamos múltiplas classes em um bloco. Essa abordagem além de dificultar a legibilidade do bloco cria especificidade sem necessidade e acopla os elementos ao bloco mais do que o necessário.
/* Esse tipo de nesting ao invés de gerar seletores 0,1,0 */
.search {
.search__item {}
.search__label {
&.search__label--floating {
}
}
}
/* Gera o CSS */
/* 0.2.0 */
.search .search__item {}
/* 0.2.0 */
.search .search__label {}
/* 0.3.0 */
.search .search__label.search__label--floating {}
O overnesting geralmente acontece pelo não conhecimento de como o Sass funciona ou pela tentativa de imitar o formato do HTML no CSS.
Como naming convention BEM é flexível quando nos apropriamos de outras arquiteturas ou apenas características delas. Como citado na documentação:
No matter what methodology you choose to use in your projects, you will benefit from the advantages of more structured CSS and UI. Some styles are less strict and more flexible, while others are easier to understand and adapt in a team.
Não importa qual metodologia você use em seus projetos, vbocê vai se beneficiar das vantagens de uma UI e CSS mais estruturados. Alguns estilos são menos estritos e mais flexíveis, outros sãi fáceis de entender e adaptar em um time.Tradução
Podemos escrever as regras do tipo block do CUBECSS na convenção do BEM.
A diferença entre os blocos do CUBECSS e do BEM é o seu escopo, no CUBE há uma separação semântica entre estrutura, configuração e aparência. Após declarar a camada de Composition que defini layouts num nível mais macro (Como o object no OOCSS ou ITCSS) e criar classes utilitárias na camada de Utility, sobra pouca configuração a se fazer na cabada do Block, o deixando mais enxuto.
Podemos também criar as diversas camadas propostas pelo ITCSS e criar Objects, Components e Utilities na sintaxe do BEM. O ITCSS não define a forma que criamos modificadores e a relação dos componentes e seus estados/variantes, mas sim a taxonomia e localização dos elementos respeitando seu escopo e dando previsibilidade na sua especificidade e posição na cascata.
Podemos expressar as mesmas relações do SMACSS, por exemplo, declarando states quando esses alteram um módulo específico na sintaxe BEM:
/* Na convenção SMACSS */
.tab {
background-color: purple;
color: white;
}
.is-tab-active {
background-color: white;
color: black;
}
/* Na convenção BEM */
.tab {
background-color: purple;
color: white;
&__is-active {
background-color: white;
color: black;
}
}
States que não são específicos de um módulo podem ser declarados como classes utilitárias ou blocos independentes.
Há muitas outras formas de se escrever BEM, não necessariamente vinculadas a uma arquitetura, como no exemplo abaixo.
Não existe 'melhor arquitetura'. Todas as metodologias já propostas são claras nos problemas que elas visam resolver, e elas não necessariamente vão resolver todos os problemas da sua organização, time ou codebase. BEM pode resolver seus problemas de acoplamento de classes e especificidade, mas talvez não resolva o de performance ou localização.
O interessante é aumentar seu gabarito de metodologias, convenções e arquiteturas e escolher sua ferramenta de acordo com os problemas que tu visa resolver.
BEM num contexto de aplicação Vue com SFC pode ser incrível quando localizamos o bloco CSS no mesmo lugar que o componente que ele estiliza, mas pode gerar muito CSS duplicado ou inutilizado se não houver uma arquitetura mais voltada pra reuso de estruturas, como OOCSS ou CUBECSS.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
méthode de recherche de fichier pycharm
Qu'est-ce que la carte de contrôle d'accès NFC
Comment résoudre Autorisation refusée
Quelles sont les plateformes de vidéos courtes ?
Qu'est-ce qu'une connexion directe indépendante ?
Quelles sont les différences entre weblogic et Tomcat
Le rôle de la balise de base
Comment échanger des pièces VV
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
