집 > 기사 > 웹 프론트엔드 > BEM CSS 아키텍처에 대해 알아야 할 모든 것

BEM CSS 아키텍처에 대해 알아야 할 모든 것

DDD원래의: 2024-10-02 06:12:02278검색

BEM에 관해 일반적으로 묻지 않는 질문에 답하기 위해 이 글을 썼습니다. 하지만 답변이 부족하면 아키텍처 개발과 이해에 영향을 미칩니다.

이 기사는 현재 CSS에 대해 잘 알고 있거나 CSS 클래스 명명 규칙을 접한 적이 없는 초보자를 대상으로 하지 않습니다. 이런 경우에는 출처 섹션으로 건너뛰세요.

공식 레거시 BEM CSS 웹사이트에서 가져온 헤더

CSS 아키텍처란 무엇인가요?
BEM CSS란 무엇입니까?
- 결합에 따른 UI 요소 분류
- CSS를 통해 컴포넌트의 관계 표현
- 복잡한 구성 요소 관계
BEM을 이용한 특이성 제어
CSS 재사용
BEM과 Sass
다른 아키텍처와의 상호작용
출처

? CSS 아키텍처란 무엇입니까?

식물처럼 코드도 어떻게 만들고, 유지하고, 어디에 위치하는지에 따라 코드가 성장하고 번영하는 방식이 달라집니다.

표준, 위치, 관리에 대한 요구 사항이 서로 다른 규정이 있듯이 토양, 처리, 물 및 햇빛에 대한 요구 사항도 서로 다른 식물이 있습니다.

CSS는 페이지 로드에 있어 중요한 요소입니다. 브라우저가 모든 HTML 및 CSS를 요청, 다운로드 및 DOM 및 CSSOM으로 변환하고 렌더링 트리를 어셈블하기 전에는 렌더링 프로세스가 시작되지 않습니다. CSS가 적을수록 성능이 향상되고 CSS가 더욱 조직화되고 표준화되고 강력해지며 유지 관리, 확장 및 압축이 더 잘됩니다.

CSS 선택기의 이름이 지정되는 방식은 규칙의 범위, 구체성, 위치 및 의미에 영향을 주어 개발 프로세스 속도를 높이거나 저하시킵니다. 여러 사람이 CSS를 작성하는 프로젝트에서는 언어 수준이 다르고 관습이나 개인 기준이 다르기 때문에 관리하지 않으면 규칙과 버그가 과도하게 반복될 수 있습니다.

? BEM CSS란 무엇입니까?

BEM은 스타일 가이드에 초점을 맞춘 CSS 아키텍처로, CSS 규칙을 분류하고 작성하기 위한 표준을 정의합니다. BEM은 하나 또는 몇 개의 스타일 시트로 관리되는 여러 페이지가 포함된 애플리케이션의 맥락에서 Yandex에서 만들어졌습니다.

BEM은 Block, Element, Modifier의 약어입니다. 이러한 각 항목은 CSS에서 직접 표현되는 인터페이스 요소의 카테고리를 나타냅니다.

Tudo o que você precisa saber sobre a arquitetura BEM CSS — 시각적으로 구분된 인터페이스 구성 요소의 표현, 출처: BEM CSS 공식 홈페이지

? 결합에 따라 UI 요소 분류

블록은 독립적인 UI 요소를 나타내며 헤더에 탐색 링크가 있는 것처럼 하위 항목을 가질 수 있으며 이러한 하위 항목이 독립적인 경우 블록이 될 수도 있습니다.

인터페이스 컴포넌트의 독립성 개념은 다음 원리로 정의할 수 있습니다

"구성 요소가 특정 컨텍스트 내에서만 의미가 있는 경우 해당 컨텍스트의 요소여야 합니다. 여러 컨텍스트에 존재할 수 있는 경우 독립 블록이어야 합니다."

요소는 또 다른 더 큰 요소를 구성하고 해당 요소에 속하는 구성 요소입니다. 이 구성 요소가 존재하지 않고 적용되는 컨텍스트에만 의존하지 않는 경우 블록일 수 있습니다. BEM에서 블록은 다른 블록을 포함할 수 있습니다. 요소가 요소를 포함해야 한다면 그 역시 블록일 가능성이 높습니다.

블록과 요소의 관계는 이중 밑줄 block__element로 표시됩니다.

블록과 요소에는 동일한 맥락 내에서 미적 변형이나 레이아웃 변형이 포함될 수 있습니다. 이를 위해 수정자가 있습니다. 이러한 클래스는 동일한 구성 요소의 다양한 상태나 변형을 나타낼 수 있습니다. 요소와 같은 수식자는 블록에 의존하며 블록에서만 파생됩니다.

블록 또는 요소와 수정자 간의 관계는 이중 대시 블록(수정자 또는 block__element-수정자)으로 표시됩니다.

Referência	Descrição
	Um checkbox é independente, pode ser aplicado dentro de outros componentes como , ou , por exemplo.
	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.

? CSS를 통해 컴포넌트의 관계 표현하기

체크박스의 예를 사용하여 구성요소를 구축하고 해당 책임을 정의하는 방식은 블록, 요소 또는 수정자가 될 수 있는 항목에 영향을 미칩니다. 이 의사결정은 다음 템플릿으로 시작됩니다.

<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 클래스의 지형이 변경됩니다. 아래 예에서 input과 label은 별도의 엔터티입니다.

<div class="column">
  <label class="label" for="checkbox">
    Default checkbox
  </label>
  <input
   class="input input--checkbox"
   type="checkbox"
   value=""
   id="checkbox"
  />
</div>

이 경우 .column은 블록이자 단순한 유틸리티 클래스로 볼 수 있습니다. 다른 CSS 아키텍처 외에도 자체 규칙을 따르는 유틸리티 클래스를 포함하여 BEM을 유틸리티 클래스와 함께 사용할 수 있습니다.
.input은 모든 입력을 참조하는 블록이며 .column 컨테이너 또는 기타 컨테이너 내에서 사용할 수 있으며 .label의 존재 여부에 관계없이 작동합니다. 여기에는 :checked 상태와 같은 체크박스 유형의 입력을 위한 특정 스타일을 로드하는 --checkbox 변형이 있습니다.
.label은 레이아웃과 모양이 입력에 의존하지 않는 블록이며 .input을 하위 요소로 가질 수도 있습니다.

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를 작은 구성 요소로 분리하면 사용된 페이지에 관계없이 이러한 부분을 재사용할 수 있습니다.

이러한 재사용 개념을 예시하기 위해 헤더와 같은 더 복잡한 구성 요소를 사용할 수 있습니다.

Tudo o que você precisa saber sobre a arquitetura BEM CSS

이 헤더는 다음과 같이 작성할 수 있습니다(짧은 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가 하나의 큰 블록으로 선언되었으며 포함된 모든 것이 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 {}

? Controle da especificidade com BEM

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:

Classes podem ser reaproveitadas
Como você se refere diretamente aos elementos usando as classes, a especificidade tende a ser sempre muito próxima de 0,1,0
Pra alterar ou sobrescrever uma regra, basta adicionar outra classe
Regras que se referem à seletores mais globais como de resets ou normalizers são facilmente sobrescritas pelas classes.

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.

? Reuso de CSS

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.

? BEM e Sass

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:

Sass permite a criação de múltiplas folhas de estilo e a co-locação dos estilos de acordo com as necessidades do projeto,logo podemos criar uma folha pra cada bloco ou conjunto de blocos que se referem a um componente ou contexto.
Sass tem suporte à concatenação de string, o que torna ainda mais visual a relação da classe com seus elementos e modificadores. Pensando no exemplo do bloco .search citado anteriormente:

.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.

? Interações com outras arquiteturas

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.

Tradução

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.

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.

BEM com nesting nativo V2 - ainda mais poderoso ?

Camilo Micheletto ・ Jun 29

#css #webdev #braziliandevs #tutorial

Afinal, BEM é a melhor arquitetura de CSS?

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.

? Fontes

Artigo BEM: guia definitivo do padrão CSS mais famoso de Tárcio Zemel (DPW), em português (Muito bom)
Vídeo BEM: A Convenção CSS Para Um Front End Muito Melhor de Tárcio Zemel (DPW), em português
Artigo An Introduction To Object Oriented CSS (OOCSS) na Smashing Magazine, em inglês
Artigo MindBEMding – getting your head ’round BEM syntax de Harry Roberts, em inglês
Artigo BEMIT: Taking the BEM Naming Convention a Step Further de Harry Roberts, em inglês
Artigo Side Effects in CSS de Phillip Walton, em inglês
Artigo BEM 101 em Smashing Magazine, em inglês

위 내용은 BEM CSS 아키텍처에 대해 알아야 할 모든 것의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

JavaScript css less html sass String Object define for while checkbox Interface dom bom display column flex input ui bug

성명：

이전 기사：Astral.CSS 탐색: 웹 디자인을 혁신하는 CSS 프레임워크.다음 기사：Astral.CSS 탐색: 웹 디자인을 혁신하는 CSS 프레임워크.