我写这篇文章的目的是回答有关 BEM 的问题，这些问题通常不会被问到，但缺乏答案会影响架构的开发和理解。
本文不针对现在已经非常了解 CSS 和/或从未接触过 CSS 类命名约定的初学者。 如果您遇到这种情况，请跳至来源部分。
标题改编自官方遗留 BEM CSS 网站
就像植物一样，代码的生长和繁荣方式取决于我们如何创建它、维护它以及事物的位置。
不同的植物对土壤、处理、水和阳光有不同的需求，就像不同的规范对标准、位置和管理有不同的需求一样。
CSS 是页面加载中的关键元素 - 在浏览器请求、下载所有 HTML 和 CSS 并将其转换为 DOM 和 CSSOM 并组装渲染树之前，渲染过程不会开始。 CSS 越少，性能就越好，CSS 越有组织、标准化和健壮，就越容易维护、管理、扩展和压缩。
CSS 选择器的命名方式会影响这些选择器的规则范围、特异性、位置和语义，从而加快或恶化开发过程。在多人编写 CSS 的项目中，我们的语言技能水平不同，习俗或个人标准也不同，如果不加以管理，可能会导致规则重复和错误过多。
BEM 是一个专注于 styleguide 的 CSS 架构，它定义了分类和编写 CSS 规则的标准。 BEM 是在 Yandex 的应用程序上下文中创建的，该应用程序包含由一个或几个样式表管理的多个页面。
BEM 是 Block、Element、Modifier 的缩写。这些实体中的每一个都代表界面元素的类别，直接用 CSS 表示。
一个Block代表一个独立的UI元素，它可以有子元素，就像标题有它的导航链接一样，这些子元素，如果它们是独立的，也可以是块。
界面组件独立性的概念可以通过以下公理来定义
“如果组件仅在特定上下文中有意义，则它必须是该上下文的元素。如果它可以存在于多个上下文中，则它必须是一个独立的块。”
元素是构成另一个较大元素并属于它的组件。如果此组件不存在并且不仅仅依赖于它所应用的上下文，那么它可以是一个块。在BEM中，块可以包含其他块，如果元素需要包含元素，那么它可能也是一个块。
块和元素之间的关系由双下划线block__element表示。
块和元素可能在同一上下文中包含美学或布局变化。为此，我们有修饰符。这些类可以表示同一组件的不同状态或变体。诸如元素之类的修饰符依赖于块并且仅从它派生。
块或元素与其修饰符之间的关系由双破折号 block--modifier 或 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. |
以 checkbox 為例，我們建構元件和定義其職責的方式會影響區塊、元素或修飾符。這個決策從模板開始：
<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>
在此範本中，我們將 .form-field 元件作為一個區塊，它將始終包含 .form-field__input 輸入和 .form-field__label 類別標籤。區塊（.form-field）和元素（標籤或輸入）之間的關係由雙下劃線表示。寫這篇文章意味著透過CSS我們了解到：
form-field 是一個獨立的實體，它的樣式工作不依賴於元件或父容器的上下文，任何表單都可以接收 .form-field 類型的欄位
反過來，表單欄位可以包含 __input 和 __label，其佈局和外觀取決於表單欄位容器
.form-field {}
.form-field__input {}
.form-field__input--checkbox {}
.form-field__label {}
當我們更改模板中的關係時，我們會更改 CSS 類別的拓撲。在下面的範例中，輸入和標籤是單獨的實體：
<div class="column">
<label class="label" for="checkbox">
Default checkbox
</label>
<input
class="input input--checkbox"
type="checkbox"
value=""
id="checkbox"
/>
</div>
用 CSS 表達，它看起來像這樣：
.column {}
.input {}
.input--checkbox {}
.input--checkbox:checked {}
.label {}
BEM 注意元件的獨立性 - 更改元件在 HTML 中的位置不應影響其佈局，更改元件的 CSS 不應影響其他元件。當我們創建元素時，我們會展示一個列表，其中列出了更改其區塊時將受到影響的內容。透過這種方式，您可以了解什麼是組件及其部件以及完全獨立的模組。如遺留文件中所引用的：
2006 年，我們開始發展第一個大型專案：Yandex.Music 和 Ya.Ru。這些長達數十頁的項目揭示了目前開發方法的主要缺點：
- 某一頁面程式碼的任何變更都會影響其他頁面的程式碼。
- 選擇類別名稱很困難。
2006 年，我們開始發展第一個大型專案：Yandex.Music 和 Ya.Ru。這些長達數十頁的項目暴露了目前開發方法的缺點：
翻譯
2010 年，當BEM 開源並獲得網站時，每個UI 元素都是一個「組件」的想法甚至在原子設計（Brad Frost，2013）之前就已經存在，以應對保持一致性的挑戰不同頁面上的相同組件。例如，當 Yandex 建立 BEM 時，他們使用了多個 HTML 檔案以及僅一個 CSS 和一個 Javascript 檔案。
如果每個頁面都是一個區塊，且其元素依賴於該頁面的上下文，則頁面之間一致的所有程式碼都會重複。將 UI 分成小元件可以重複使用這些部分，無論它們在哪個頁面上使用。
為了舉例說明重用的概念，我們可以使用更複雜的元件，例如標頭：
這個標題可以寫成如下（短HTML）：
<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>
請注意，在此範例中，整個導覽列被宣告為一個大塊，並且它包含的所有內容都被視為 navbar 的 元素。結果，我們失去了多次重用的機會。
| 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... */
}
登录后复制 |
 |
.nav {
display: flex;
gap: 1rem;
/* etc... */
}
登录后复制 |
 |
.breadcrumb {
display: flex;
gap: 0.5rem;
/* etc... */
}
登录后复制 |
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.
以上是关于 BEM CSS 架构您需要了解的一切的详细内容。更多信息请关注PHP中文网其他相关文章！
