Metodologias CSS(1) BEM

BEM ¿Que es eso?

Es una metodología de nomenclatura css.
Propone nombrar las clases así: Bloque__Elemento–Modificador.

Bloques serian porciones de la pagina con un contenido y/o uso diferenciado (como un menú) , elementos los elementos de un bloque (como un botón de menú) y modificadores aquellos aspectos que cambian el diseño de un elemento o bloque (como desactivar un botón).

Por ejemplo:
.contact__button–disabled
.contact__button
.header__logo–orange

¿Por que usa dos guiones?

Para distinguir que partes forman parte de la nomenclatura Bloque__Elemento–Modificador y que partes no, como por ejemplo:

.contact__button–disabled-big

¿Por que alterna guion medio y bajo?

Para distinguir los modificadores de los elementos cuando se apliquen a un bloque, así por ejemplo vemos que disabled es un modificador y no un elemento

.contact–disabled

Pero… ¿no seria mejor poner “header .logo.orange” por ejemplo y aprovechar la herencia?

No, BEM dice que no.
Dice que la herencia es mala, caca, porque es impredecible causa muchos problemas y mejor no usarla.

Pe-pe-pe-…pero ¡Mi amada herencia! ¡La primera C de CSS es de cascada por la herencia! ¡Estais matando CSS!

Si.
BEM dice que la herencia impide reutilizar bloques de una parte a otra, y que gran parte del trabajo de css es resetear y sobreescribir valores heredados. Ademas confiar en la herencia complica el trabajo cuando varios developers trabajan sobre el mismo proyecto.
BEM propone eliminar la herencia por completo y definir cada elemento por separado, y no utilizar tags en los css, solo clases.

¿Y no será un coñazo tener que andar reescribiendo lo mismo en cada elemento de cada bloque?

No si usas sass.
Con sass puedes replicar la herencia natural de css a una herencia de archivo fuente sass, ya que puedes escribir el código una sola vez y reutilizarlo con includes y extends.
.header__navigation { 
background: #008cba; 
padding: 1rem 0; 
margin: 2rem 0; 
text-transform: uppercase; 

.header__navigation–secondary { 
@extend .header__navigation;
background: #dfe0e0; 
}

Esto llenara de morralla el css, y los htmls serán kilometricos con clases tan largas…

Bueno, a BEM le da igual, según él compensa por las ventajas que trae.

¿Cuales?

Las derivadas de que cada clase sea totalmente independiente, sobre todo, poder reutilizar elementos sin preocuparse de que hereden valores según se pongan en una parte u otra de la pagina. En proyectos grandes (y/o con varios diseñadores) facilita tener un control del diseño, es más predecible.

¿Y a tí te gusta?

En principio no. A mi me gusta la herencia, los tags semanticos de html5, el viejo buen CSS que nos enseñaron nuestros antepasados.

Es una metodología como hay otras, y no hay una mejor que otra, hay usos mejores que otros, la DRY por ejemplo propone prácticamente lo contrario.
Y cada una tiene sus ventajas e inconvenientes. La herencia nos ha dado mucho y satanizarla está feo.

En la mayoría de sitios donde me he informado, ponían ejemplos de problemas provocados por la herencia que parecían de teletienda, y en realidad se podrían haber solucionado con una planificación correcta del css y un uso inteligente de la herencia sin necesidad de hiperdefinirlo todo con BEM.

Pero claro, a uno se le revuelven las tripas cuando le proponen renunciar a algo como la herencia de CSS, aunque luego lo vas pensando….y te puede pasar como a este hombre

 

 

Y es que tiene cosas positivas, por ejemplo separar la jerarquía de diseño de la jerarquía de la estructura del html.

Con CSS “tradicional”, uno aprovecha la herencia “de localización” en la pagina, la anidación del css es un reflejo de la anidación en el html.
Si un elemento hereda unas propiedades es porque esta fisicamente dentro del otro elemento

El li que está dentro de nav que está dentro de header:
header > nav > li

Con BEM se sustituye por una anidación “de diseño” y ya no importa donde se localice en la pagina sino que se hace una pseudoherencia con el sistema de nomenclatura de la clase.
Podríamos sacar un botón del navegador por cualquier motivo y seguiría estando clara su pseudoherencia y seguiria funcionando:

El boton que pertenece al navegador:
navegador__boton–activo

Normalmente, es correcto que la estructura de anidación del  css refleje la del html pero no tiene porque hacerlo siempre.

Puedo imaginar que es muy útil cuando hay varios diseñadores trabajando en un proyecto grande donde la herencia da mas problemas que soluciones, también creo que es mas fácil aprovechar la herencia en un proyecto mas pequeño o liderado por una sola persona.

Y también puedo imaginar un mundo alternativo  horrible donde la herencia no existe en los css, los archivos se llaman “.ss”  y el ultimo grito es una librería que la añade  (Cascade.js).

Supongo que como de costumbre, en un mundo tan atomizado como el del html, lo bueno sera quedarse con lo que interese y desarrollar sistemas mixtos adaptados a lo que necesitemos.

Leave a Reply

Your email address will not be published. Required fields are marked *