¿Qué es la metodología BEM en HTML y CSS?

¿Qué es la metodología BEM en HTML y CSS?
¿Qué es la metodología BEM en HTML y CSS?

BEM es una metodología CSS (o convención de nomenclatura) utilizada en todo el mundo. Siga leyendo para descubrir qué es CSS BEM, ventajas de su uso, mejores prácticas con BEM, ejemplos de escritura y mucho más.

BEM nació como parte de un marco de desarrollo completo para Yandex, el motor de búsqueda con la mayor participación de mercado en Rusia, aunque desconocido en la Tierra de Santa Cruz, es uno de los motores de búsqueda más utilizados en el mundo, con cientos de millones de búsquedas por día .

Este patrón de nombres se volvió tan bueno y tan eficiente que solo fue superado por el petróleo y el gas en las exportaciones de Rusia al mundo (broma).

Como verás en nuestro completo tutorial sobre BEM, la metodología tiene una simplicidad y efectividad inusuales, lo que te permite aprender y comenzar a usarla de inmediato .

¿Qué es BEM?

Personas de todo el mundo están tratando de encontrar las mejores prácticas para trabajar con el desarrollo web . Después de todo, todos quieren lograr mejores resultados con menos esfuerzo, ¿verdad?

El personal de Yandex, el motor de búsqueda ruso más relevante, logró alcanzar un estándar notable de nomenclatura, logrando combinar simplicidad y facilidad con muchas ventajas de implementación.

Su nombre es BEM .

Y aquí viene el primer pequeño secreto: BEM, de hecho, es un acrónimo de Block , Element y Modifier . Estos son los 3 pilares del estándar BEM, cada uno con su propio significado, función y reglas de escritura.

Según Varya Stepanova , uno de los desarrolladores front-end que ha sido parte del propio equipo de BEM de Yandex,

BEM alude a la Programación Orientada a Objetos (OOP), una forma de describir la realidad en el código, con una variedad de patrones y una forma de pensar sobre las entidades del programa.

Y, realmente, es posible notar esta alusión a POO en el uso de BEM para nombrar «entidades» en CSS. Con la práctica y el tiempo de uso, este principio se vuelve más evidente.

Reglas de bloque, elemento y modificador

Como se mencionó, cada una de las letras del acrónimo BEM tiene su función específica dentro de la metodología, a veces se utiliza por separado, a veces en coordinación con las demás.

Y son precisamente estas reglas de escritura y las respectivas funciones de Bloque, Elemento y Modificador las que se explicarán a continuación.

Bloque

En BEM, un bloque es una entidad independiente, un «bloque de construcción» de una aplicación; una abstracción más general, con significado propio.

Si está acostumbrado a otras convenciones / metodologías (como SMACSS), para hacerlo más fácil, puede considerar un Bloque como Componente o Módulo.

El bloque es la parte del crack con más flexibilidad en la nomenclatura, lo que significa que puede nombrar la «entidad» de la forma que desee, incluso junto con otras convenciones, como los espacios de nombres CSS.

Elemento

Un elemento es parte de un bloque; es un elemento hijo. Un Elemento no tiene función / significado independiente y está semánticamente vinculado a su respectivo Bloque.

Los elementos tienen una regla específica de la escritura, siendo una clase CSS compuesto por Nombre del bloque elemento de nombre + 2 __ (subrayados) : .[Bloque]__[Elemento].

Por ejemplo, si tiene un bloque .c-menu, un elemento del mismo puede ser .c-menu__item.c-menu__link.

Dentro de las reglas de escritura de BEM, estos 2 subrayados representan un Elemento. Tenga en cuenta que esto no viola las reglas de nomenclatura CSS, al tiempo que deja muy claro de qué se trata, ya que es de conocimiento común (entre los desarrolladores frontales) que __es un Elemento BEM.

Modificador

Como sugiere su nombre, un modificador BEM se utiliza para … Modificar. ¿Pero modificar qué? Puede ser un bloque o un elemento.

Así es: un Modificador se puede aplicar a un Bloque o un Elemento, sirviendo como una variante usada para cambiar su apariencia, variar una propiedad o asignar un estado.

Su regla de escritura es una clase compuesta de la nombre de un bloque o dos guiones modificador + — + el nombre del modificador : [Bloque|Elemento]--[Modificador].

Siguiendo el ejemplo, podría haber un modificador de menú .c-menu--dark para una versión oscura; una versión del menú fijada con .c-menu--fixedo; para enlaces deshabilitados .c-menu__link--disabled.

Ejemplo práctico de BEM

Ahora que se han explicado las razones para ser un bloque, un elemento y un modificador y se presentan sus convenciones de escritura, vale la pena corregir un ejemplo más completo.

Siguiendo el mismo ejemplo que un menú, podría tener el siguiente código HTML:

Note el salto del gato:Al observar una estructura HTML que usa BEM, es posible deducir cómo se ve la estructura de reglas CSS y viceversa.

Entonces, cuando se enfrenta al HTML anterior, ya es posible sospechar que el CSS tendrá una estructura similar a:

¿Es o no es la cosa más simple del Universo?

Mejores prácticas para escribir BEM

Si está comenzando a conocer BEM ahora, o incluso si lo ha estado utilizando durante algún tiempo, es interesante conocer las mejores prácticas de BEM para asegurarse de que está escribiendo código de calidad.

No replique la jerarquía HTML en el nombre de las clases BEM

¿Notó, en el ejemplo anterior, que el enlace no recibió la clase .c-menu__item__link? La jerarquía HTML era exactamente eso ( ul > li > a), pero la clase Element omitió «__item» del nombre.

Esto se debe a que no es necesario replicar exactamente la estructura de HTML para componer los nombres de las clases en BEM. Si es así, imagina el tamaño de los nombres de clase de bloques más complejos …

De hecho, una de las principales críticas negativas a BEM es que la adopción de la metodología hace que el código sea muy detallado, con nombres muy largos.

En parte, esto puede ser cierto, pero muchos de los críticos desconocen esta buena práctica de escritura y no usan nombres muy cortos, como los del ejemplo.

Recuerda que puedes usar nombres compuestos

Pero hay casos en los que, sí, sería bueno escribir algo con diferentes niveles de jerarquía (pero no exactamente replicar todo).

Imagina un caso como este .c-card__wrapper__info__image.

A pesar de la extensión, el nombre de la clase es muy descriptivo y tiene un buen nivel de especificidad CSS. Parece que la única desventaja es realmente el tamaño de este nombre de clase.

Pero nombres tan importantes pueden cansarlo de leer (además de aumentar el peso final de los archivos HTML). E imagina este elemento con 2 o 3 Modificadores, cuyos nombres deben contener el nombre del Bloque …

Para casos como este, solo debes preocuparte de lo siguiente: proporcionar un nombre único, que deje al elemento inequívocamente identificable entre los demás.

Una posible sugerencia sería el nombre compuesto .c-card__info-image(asumiendo que el componente tendrá más de una imagen).

Si es el caso de que solo haya 1 imagen en todo el componente, incluso funcionaría .c-card__image, incluso en HTML, el elemento debería estar en un nivel de jerarquía más profundo.

Bloques dentro de bloques

Es bastante común en el desarrollo diario del front-end que sea necesario tener Bloques dentro de Bloques o Componentes dentro de Componentes, si está más acostumbrado a esta nomenclatura.

Entonces, puede ser necesario modificar ligeramente la apariencia de un bloque interno cuando está contenido en uno externo.

Por ejemplo, un bloque .c-buttondentro de .c-card:

Dentro de este escenario, .c-button ya se ha determinado su apariencia, ya que es un componente utilizado en muchos lugares del sitio. Pero en este caso, debe ser un poco más grande cuando está dentro de uno .c-card.

¿Cuál es el mejor enfoque? ¿Crear un modificador para el botón? 🤔

Incluso podría ser el caso de crear un Modificador .c-button--large, pero en tales casos, podría preguntarse: ¿se puede usar este modificador para agrandar el botón en otra parte del sitio o solo dentro de la Tarjeta?

Si es así, entonces realmente vale la pena crear el Mod; si no, es el caso de un estilo que afectará al Botón solo cuando esté dentro de la Tarjeta:

Es una diferencia que puede parecer sutil para algunos, pero que marca la diferencia en la práctica.

Y, además, no hay nada que impida que se cree de esa manera y, si se nota que será necesario usar un botón más grande en otra parte del sitio, refactorice el código para la creación de .c-button--large.

Cómo tratar con los estados

A raíz del ejemplo anterior, .c-card podría necesitar un estado «activo», en el que el componente se destacaría en relación con los demás (tal vez cambiando su color de fondo o colocando un borde especial).

Entre las posibles soluciones, destacan 2 posibilidades para este caso:

La primera alternativa sin duda hace que el código sea más consistente y estandarizado para BEM; el segundo es más sencillo e igualmente eficaz (además de facilitar las manipulaciones a través de JavaScript).

La verdad es que ninguno de ellos puede considerarse incorrecto y usar cualquiera de los enfoques será suficiente. Realmente depende de usted definir el estándar que se utilizará en tales casos y seguirlo durante todo el proyecto.

Pero es bastante común que se usen otras convenciones de nomenclatura junto con BEM en proyectos; por lo tanto, si ya se están utilizando espacios de nombres CSS, podría tener más sentido elegir is-active.

BEM y Sass

Si usa Sass en sus proyectos frontales, aquí tiene buenas noticias: ¡ Sass proporciona integración nativa con BEM!

Entonces, solo use el famoso &(Ampersand) de Sass para generar clases cortas, sin sobrecalificación y especificidad adecuada.

Por ejemplo:

Compila para:

Además, por supuesto, de tener todo el arsenal de funcionalidades a disposición de Sass.

Conclusión

Así que esta es la famosa metodología BEM , acrónimo de Block, Element and Modifier, crack famoso por su facilidad y sencillez de uso que aporta numerosas ventajas a los proyectos front-end que la adoptan.

Algunos desarrolladores tienen una queja: “¡Además de ser detallado, BEM es feo!”. Parece que el tener varios __-- todo HTML y CSS no le agrada a todo el mundo.

Si, para usted (o su equipo), deja de usar esta sintaxis, vale más que:

  • Código desacoplado;
  • Reutilización automática de código;
  • Menos repeticiones;
  • Identificación rápida de estructuras HTML a través de CSS (y viceversa);
  • Independencia de clase;
  • Selectores más pequeños y de mayor rendimiento;
  • CSS más mantenible.

Entonces, realmente, no deberías usar BEM …

La decisión es tuya. ¡Esperamos que elija BEM!

Sé el primero en comentar

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*