BEM에 관해 일반적으로 묻지 않는 질문에 답하기 위해 이 글을 썼는데, 답변이 부족하여 아키텍처 개발과 이해에 영향을 미칩니다.
이 기사는 현재 CSS에 대해 잘 알고 있거나 CSS 클래스 명명 규칙을 접한 적이 없는 초보자를 대상으로 하지 않습니다. 이런 경우에는 출처 섹션으로 건너뛰세요.
공식 레거시 BEM CSS 웹사이트에서 가져온 헤더
식물처럼 코드도 어떻게 만들고, 유지하고, 어디에 위치하는지에 따라 코드가 성장하고 번영하는 방식이 달라집니다.
표준, 위치, 관리에 대한 요구 사항이 서로 다른 규정이 있듯이 토양, 처리, 물 및 햇빛에 대한 요구 사항도 서로 다른 식물이 있습니다.
CSS는 페이지 로딩의 중요한 요소입니다. 브라우저가 모든 HTML 및 CSS를 요청, 다운로드 및 DOM 및 CSSOM으로 변환하고 렌더링 트리를 어셈블하기 전에는 렌더링 프로세스가 시작되지 않습니다. CSS가 적을수록 성능이 향상되고 CSS가 더욱 조직화되고 표준화되고 강력해지며 유지 관리, 확장 및 압축이 더 잘됩니다.
CSS 선택기의 이름이 지정되는 방식은 규칙의 범위, 구체성, 위치 및 의미에 영향을 주어 개발 프로세스 속도를 높이거나 저하시킵니다. 여러 사람이 CSS를 작성하는 프로젝트에서는 언어 수준이 다르고 관습이나 개인 기준이 다르기 때문에 관리하지 않으면 규칙과 버그가 과도하게 반복될 수 있습니다.
BEM은 스타일 가이드에 초점을 맞춘 CSS 아키텍처로, CSS 규칙을 분류하고 작성하기 위한 표준을 정의합니다. BEM은 하나 또는 몇 개의 스타일 시트로 관리되는 여러 페이지가 포함된 애플리케이션의 맥락에서 Yandex에서 만들어졌습니다.
BEM은 Block, Element, Modifier의 약어입니다. 이러한 각 항목은 CSS에서 직접 표현되는 인터페이스 요소의 카테고리를 나타냅니다.
블록은 독립적인 UI 요소를 나타내며 헤더에 탐색 링크가 있는 것처럼 하위 항목을 가질 수 있으며 이러한 하위 항목이 독립적인 경우 블록이 될 수도 있습니다.
인터페이스 컴포넌트의 독립성 개념은 다음 원리로 정의할 수 있습니다
"구성 요소가 특정 컨텍스트 내에서만 의미가 있는 경우 해당 컨텍스트의 요소여야 합니다. 여러 컨텍스트에 존재할 수 있는 경우 독립 블록이어야 합니다."
요소는 또 다른 더 큰 요소를 구성하고 해당 요소에 속하는 구성 요소입니다. 이 구성 요소가 존재하지 않고 적용되는 컨텍스트에만 의존하지 않는 경우 블록일 수 있습니다. BEM에서 블록은 다른 블록을 포함할 수 있습니다. 요소가 요소를 포함해야 한다면 그 역시 블록일 가능성이 높습니다.
블록과 요소의 관계는 이중 밑줄 block__element로 표시됩니다.
블록과 요소에는 동일한 맥락 내에서 미적 변형이나 레이아웃 변형이 포함될 수 있습니다. 이를 위해 수정자가 있습니다. 이러한 클래스는 동일한 구성 요소의 다양한 상태나 변형을 나타낼 수 있습니다. 요소와 같은 수식자는 블록에 의존하며 블록에서만 파생됩니다.
블록 또는 요소와 해당 수정자 사이의 관계는 이중 대시 블록--수정자 또는 block__element--수정자로 표시됩니다.
| 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... */
}
Salin selepas log masuk |
 |
.nav {
display: flex;
gap: 1rem;
/* etc... */
}
Salin selepas log masuk |
 |
.breadcrumb {
display: flex;
gap: 0.5rem;
/* etc... */
}
Salin selepas log masuk |
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.
Atas ialah kandungan terperinci Semua yang anda perlu tahu tentang seni bina CSS BEM. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Bagaimana untuk menetapkan textarea baca sahaja
Bagaimana untuk membuka kebenaran skop
Bagaimana untuk mengambil tangkapan skrin pada telefon mudah alih Huawei
Apakah sistem Honor?
Cara melaksanakan senarai terpaut dalam go
Bagaimana untuk memasuki laman web 404
Cara menukar bandar di Douyin
Bagaimana untuk memadam karya anda sendiri di TikTok
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
