Saudações. Neste artigo, mostrarei como você pode alterar o BEM, mantendo seus melhores recursos e se livrando dos piores.
Então, primeiro, vamos falar sobre o que há de errado com o BEM? Talvez nada precise ser mudado e tudo esteja tão bem?
O BEM é uma metodologia que permite que você use CSS / HTML / JS várias vezes. Ela apresenta os conceitos de bloco, elemento, modificador e mix. Ao começar a usá-lo, você entende que é exatamente isso que você espera há muitos anos; é tão conveniente, claro e bonito! Mas, após algum tempo, começam a ocorrer momentos em desenvolvimento que podem ser resolvidos com o BEM, mas isso não traz prazer nem, mais importante, benefícios. Do que estou falando? Vamos passar por estes pontos:
1. Blocos e itens descartáveis
Esse problema me incomodou tanto que me fez escrever este artigo.
O conceito de bloco implica em uma entidade que pode e deve ser reutilizada; no entanto, na prática, é criado um grande número de blocos que são aplicados uma vez.
Por exemplo, precisamos fazer o seguinte: coloque um cabeçalho na página, seguido por um campo de texto e um botão de envio, conforme mostrado na figura:
O que faremos de acordo com o BEM? Existem várias opções:
- Crie um bloco de formulário e seus elementos: título, botão, campo de texto
- Crie blocos separados para cada um dos componentes (botão, caixa de texto, título) e também para o formulário
- ...
Qualquer que seja a sua escolha, teremos um problema: como definir o recuo entre todos esses blocos?
Se escolhermos a primeira opção, poderemos decidir recuar os elementos do formulário, porque isso não contradiz a metodologia. No entanto, nesse caso, destruímos a essência do bloco: ele não pode ser reutilizado, pois sua marcação interna será adequada apenas à situação atual.
Se escolhermos a segunda opção, seria possível misturar algum bloco no formulário e os elementos desse bloco para os componentes do formulário. E, consequentemente, para os elementos do bloco recém-criado, defina o recuo. E aqui aparece o problema dos blocos únicos: eles são criados para uso em apenas um lugar! Eles não podem mais ser usados porque os componentes estarão localizados de maneira diferente em outras páginas.
Esse problema gera blocos / elementos
___size_ , bem como modificadores do tipo
___size_ ou
___place_---- (para definir o recuo), que, como já foi dito, são usados uma vez e desorganizam os arquivos de marcação e o projeto com seus próprios diretórios e arquivos.
O mesmo se aplica não apenas à indentação, mas também aos tamanhos de bloco (para botões, por exemplo, isso geralmente leva a uma alteração na
line-height ), tamanhos de fonte, indentação etc.
2. Nomes longos de classe
Não há muito o que falar. Acho que ninguém gosta da marcação, mais ou menos assim:
<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. Valores padrão ou temas de bloco
Suponha que tenhamos um bloco de botões. Você precisa estilizá-lo de acordo com os requisitos de design. Mas em outro projeto, também haverá uma classe de botão. Será diferente, mas alguns dos estilos serão os mesmos. O que o BEM recomenda fazer? Ele diz para criar um modificador de tema e configurá-lo para todos os elementos necessários.
Mas com essa abordagem, o seguinte será o seguinte:
<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>
Isso é uma confusão de código e é ruim.
Você critica - oferta
O que eu proponho para corrigir essa desgraça? Proponho o seguinte manifesto, que é essencialmente um complemento para o BEM padrão.
Manifesto - BEM aprimorado
A.1 Camada de módulos e camada de página
Proponho dividir o estilo em duas partes:
A primeira parte é a camada de componentes. Esta parte foi escrita de acordo com todas as regras (quase *) do BEM. Ele define estilos para blocos reutilizáveis, ou melhor, componentes, por exemplo, para um botão, campo de texto, título etc.
A outra parte é a camada da página. É necessário definir os estilos de blocos e elementos de uma página específica. Consequentemente, esses blocos / elementos serão usados uma vez (em qualquer caso, em uma página). As regras do BEM não se aplicam aqui. É assim:
Arquivo:
index.css .___send-button { margin-bottom: 2px; font-size: 13px; } .___message-textarea { width: 240px; height: 300px; font-size: 14px; }
O nome do arquivo de layout da página é opcional. O principal é que ele corresponda à essência da página. Todos os estilos começam com '___', para que não possam ser confundidos com as classes de entidade padrão do BEM. Além disso, as classes não estão vinculadas às entidades do BEM - seus nomes refletem apenas o que devem ser aplicados. Também é importante notar que todos os estilos do layout da página estão localizados em um arquivo, pois estão relacionados a uma página.
Essa separação nos permite resolver o primeiro problema, sem prejuízo do objetivo principal do BEM - criar estilos / marcações para que possam ser reutilizados. Esses estilos serão aplicados em apenas uma página e de forma alguma interferirão nos estilos dos componentes do layout dos componentes. Assim, nos livramos das classes únicas, mantendo a capacidade de reutilizar blocos e sem violar o escopo.
Também faz sentido separar componentes e layouts de página no nível do diretório.
* exceto para as regras que são canceladas pelos seguintes parágrafos do manifesto.A.2 Nomes longos de classe
(Item experimental, portanto opcional *)
Propõe-se substituir parte do sistema de nomes padrão pelo seguinte:
Para bloco:
class="" (sem alteração)
Para um bloco com um modificador:
class=" _" (acesso através do seletor combinado.
.._ )
Para um elemento:
class="__" (sem alteração)
Para um elemento com um modificador:
class="__ _" (acesse por meio de
.__._ )
Este item permite que você obtenha um código curto sobre modificadores. Obviamente, o mesmo não pode ser feito com elementos.
É importante que os arquivos com estilos não tenham regras definidas para seletores que consistem apenas em modificadores:
._active { background-color: #abcdef; }
* nomes similares de modificadores podem levar a problemas em blocos / elementos misturados com outros blocos / elementos, desde que ambas as entidades possam ter o mesmo modificador. Ou seja, ao definir um modificador para uma entidade, o definimos para todos os que estão misturados nesse nó.A.3 Padrões e temas
Tudo é simples aqui. É proposto escolher um tema padrão, mas prescrever estilos para ele, não na classe de bloco que está no arquivo de bloco, mas na classe de bloco que deve ser colocada no arquivo de tema. Por exemplo:
Arquivo -
button/button.css .button { cursor: pointer; display: inline-block; }
Arquivo -
button/_theme/button_theme_P2.css .button_theme_P2, .button { border-radius: 3px; border: 1px solid #f00; }
Ou de acordo com o parágrafo 2
.button._theme_P2, .button { border-radius: 3px; border: 1px solid #f00; }
Portanto, este tópico se torna padrão, mas você pode usá-lo diretamente, se desejar.
Sumário
Este manifesto foi projetado para resolver alguns dos problemas que surgem durante o layout, de acordo com o BEM. Seu principal componente era uma divisão no layout dos componentes e no layout da página. Embora o manifesto pareça bastante revolucionário, misterioso e ousado, ele resolve os problemas declarados. Para usar tudo, parcialmente ou não usá-lo - é claro, você decide.
PS Se você agora está rolando a página com raiva para colocar um sinal de menos, não esqueça de escrever um comentário, caso contrário, seu sinal de menos não trará nenhum benefício (
assim como o manifesto ).