
Saludos En este artículo, le diré cómo puede cambiar BEM, conservando sus mejores características y deshaciéndose de las peores.
Entonces, primero, hablemos sobre lo que está mal con BEM. ¿Quizás nada necesita ser cambiado y todo es tan bueno?
BEM es una metodología que le permite usar CSS / HTML / JS muchas veces. Ella presenta los conceptos de bloque, elemento, modificador y mezcla. Al comenzar a usarlo, comprende que esto es exactamente lo que ha estado esperando durante muchos años, ¡es tan conveniente, claro y hermoso! Pero después de un tiempo, comienzan a ocurrir esos momentos en el desarrollo que pueden resolverse con la ayuda de BEM, pero esto no brinda placer ni, lo más importante, beneficios. De que estoy hablando Veamos estos puntos:
1. Bloques y artículos desechables
Este problema me molestó tanto que me vi obligado a escribir este artículo.
El concepto de bloque implica una entidad que puede y debe reutilizarse, sin embargo, en la práctica, se crea una gran cantidad de bloques que se aplican una vez.
Por ejemplo, debemos hacer lo siguiente: colocar un encabezado en la página, seguido de un campo de texto y un botón de enviar, como se muestra en la imagen:

¿Qué haremos según BEM? Hay varias opciones:
- Cree un bloque de formulario y sus elementos: título, botón, campo de texto.
- Cree bloques separados para cada uno de los componentes (botón, cuadro de texto, título), así como para el formulario
- ...
Lo que elijamos, tendremos un problema: ¿cómo establecer la sangría entre todos estos bloques?
Si elegimos la primera opción, entonces podemos decidir sangrar los elementos del formulario, porque esto no contradice la metodología. Sin embargo, en este caso, destruimos la esencia del bloque: no se puede reutilizar, ya que su marcado interno solo se ajustará a la situación actual.
Si elegimos la segunda opción, entonces sería posible mezclar algún bloque con el formulario, y los elementos de este bloque para mezclar con los componentes del formulario. Y, en consecuencia, para los elementos del bloque recién creado, establezca la sangría. Y aquí aparece el problema de los bloques únicos: ¡se crean para usar en un solo lugar! Ya no se pueden usar porque los componentes se ubicarán de manera diferente en otras páginas.
Este problema genera bloques / elementos
___size_
, así como modificadores del tipo
___size_
o
___place_----
(para sangría), que, como ya se ha dicho, se usan una vez y desordenan tanto los archivos de marcado como el proyecto con sus propios directorios y archivos.
Lo mismo se aplica no solo a la sangría, sino también a los tamaños de bloque (para botones, por ejemplo, esto a menudo conduce a un cambio en
line-height
), tamaños de fuente, sangría, etc.
2. Nombres de clase largos
Ni siquiera hay mucho de qué hablar. No creo que a nadie le guste el marcado que se parece a esto:
<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 predeterminados o temas de bloque
Supongamos que tenemos un bloque de botones. Debe estilizarlo de acuerdo con los requisitos de diseño. Pero en otro proyecto también habrá una clase de botón. Se verá diferente, pero algunos de los estilos serán los mismos. ¿Qué recomienda hacer BEM? Él dice que cree un modificador de tema y lo configure en todos los elementos requeridos.
Pero con este enfoque, resultará lo siguiente:
<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>
Este es un desorden de código, y es malo.
Usted critica - ofrece
¿Qué propongo para corregir esta desgracia? Propongo el siguiente manifiesto, que es esencialmente un complemento del BEM estándar.
Manifiesto - BEM mejorado
A.1 Capa de módulos y capa de página
Propongo dividir el estilo en dos partes:
La primera parte es la capa de componentes. Esta parte está escrita de acuerdo con todas las reglas BEM (casi *). Establece estilos para bloques reutilizables o, más bien, componentes, por ejemplo, para un botón, campo de texto, título, etc.
La otra parte es la capa de la página. Es necesario establecer los estilos de bloques y elementos de una página en particular. En consecuencia, estos bloques / elementos se utilizarán una vez (en cualquier caso, en una página). Las reglas BEM no se aplican aquí. Se ve así:
Archivo:
index.css
.___send-button { margin-bottom: 2px; font-size: 13px; } .___message-textarea { width: 240px; height: 300px; font-size: 14px; }
El nombre del archivo de diseño de página es opcional. Lo principal es que coincide con la esencia de la página. Todos los estilos comienzan con '___' para que no se puedan confundir con las clases de entidad BEM estándar. Además, las clases no están vinculadas a entidades BEM: sus nombres solo reflejan a qué se deben aplicar. También vale la pena señalar que todos los estilos de diseño de página se encuentran en un archivo, ya que se relacionan con una página.
Esta separación nos permite resolver el primer problema, sin perjuicio del objetivo principal de BEM: crear estilos / marcas para que puedan reutilizarse. Estos estilos se aplicarán en una sola página y de ninguna manera interferirán con los estilos de los componentes del diseño de componentes. Por lo tanto, nos deshacemos de las clases únicas, mientras mantenemos la capacidad de reutilizar bloques y sin violar el alcance.
También tiene sentido separar componentes y diseños de página a nivel de directorio.
* a excepción de las reglas que se cancelan en los siguientes párrafos del manifiesto.A.2 Nombres de clase largos
(Experimental, por lo tanto, elemento opcional *)
Se propone reemplazar parte del sistema de nombres estándar con lo siguiente:
Para el bloque:
class=""
(sin cambios)
Para un bloque con un modificador:
class=" _"
(acceso a través del selector combinado.
.._
)
Para un elemento:
class="__"
(sin cambios)
Para un elemento con un modificador:
class="__ _"
(acceso a través de
.__._
)
Este artículo le permite obtener un código corto con respecto a los modificadores. Obviamente, no se puede hacer lo mismo con los elementos.
Es importante que los archivos con estilos no tengan reglas definidas para los selectores que consisten solo en modificadores:
._active { background-color: #abcdef; }
* los nombres similares de los modificadores pueden generar problemas en los bloques / elementos mezclados con otros bloques / elementos, siempre que ambas entidades puedan tener el mismo modificador. Es decir, al configurar un modificador para una entidad, lo configuramos para todos los que se mezclan con este nodo.A.3 Valores predeterminados y temas
Todo es simple aquí. Se propone elegir un tema predeterminado, pero prescribir estilos para él, no en la clase de bloque que está en el archivo de bloque, sino en la clase de bloque que debe colocarse en el archivo de tema. Por ejemplo:
Archivo -
button/button.css
.button { cursor: pointer; display: inline-block; }
Archivo -
button/_theme/button_theme_P2.css
.button_theme_P2, .button { border-radius: 3px; border: 1px solid #f00; }
O de acuerdo con el párrafo 2
.button._theme_P2, .button { border-radius: 3px; border: 1px solid #f00; }
Por lo tanto, este tema se convierte en estándar, pero puede usarlo directamente si lo desea.

Resumen
Este manifiesto está diseñado para resolver algunos de los problemas que surgen durante el diseño de acuerdo con BEM. Su componente principal fue un desglose en el diseño de los componentes y el diseño de la página. Aunque el manifiesto parece bastante revolucionario, poco canónico y audaz, resuelve los problemas planteados. Para usarlo todo, parcialmente o no usarlo, por supuesto, usted decide.
PD: si ahora te desplazas con enojo por toda la página para poner un menos, no olvides escribir un comentario; de lo contrario, tu menos no traerá ningún beneficio (
así como el manifiesto ).