Consejos para mejorar tu CSS (nivel principiante)

Si habéis leído alguno de mis artículos, os daréis cuenta que el Fron-end (la parte frontal de la aplicación, la que queda a la vista) no es mi fuerte.

Así que hoy os traigo una guía de consejos que podemos encontrar en uno de los episodios premium del Podcast de Daniel Primo: Buenos consejos para un buen CSS.

La intro era para que no me matéis si digo alguna barbaridad en este artículo, jeje.

CSS no es considerado un lenguaje de programación per se, aunque habría que darse una vueltecita por SASS o LESS para sacar una conclusión rotunda al respecto. Pero esto no quiere decir que no sea necesario seguir unas buenas prácticas para obtener unos archivos de hoja de estilo que sigan unos estándares o que nos permitan que la aplicación sea extensible con el menor trabajo posible.

¡Ojo a lo que te digo! Si estás acostumbrado a trabajar con CSS y te consideras un usuario avanzado…

¡Sal de aquí pitando!

Vamos a ver algunos de los consejos que se pueden seguir a la hora de darle una mano de pintura al UI.

Divide tu código en varios hojas si fuera necesario ¶

Si bien estamos más que acostumbrados (todos aquellos que hemos tocado algo de CSS a nivel principiante) a tener un archivo custom.css que contenga todo el código CSS de nuestra aplicación, se considera una buena práctica dividir nuestro código en archivos aún más concisos.

¿Qué ventaja real tiene esto?

• Tus archivos CSS serán más pequeños.
• La funcionalidad de cada uno de los CSS será más concisa, con lo que será más sencillo encontrar el código a modificar.
• Será más complicado que los selectores entren en conflicto con otros selectores.

La forma en que organices tu CSS depende mucho de tu forma de enfocar la escritura del mismo.

En el terreno de la programación sería algo así como lo que hacemos con las clases, módulos o plugins; que tendemos a separar en carpetas.

Comentarios ¶

Si hay una cosa que queda clara cuando vemos lenguaje de estilos, es que este lenguaje declarativo no se explica muy bien por si solo.

Es por esto que se aconseja utilizar comentarios dentro de las hojas de estilos a varios niveles:

• Alto nivel: cuando se explican funcionalidades genéricas sobre el código o grandes bloques que comprenden varios componentes.
• Bajo nivel: cuando se especifican funcionalidades a nivel de declaraciones específicas.

Comentemos a un nivel u otro, la multilínea está más que aceptada y un comentario en CSS se vería así:

/**
*
* Esto es un comentario en CSS
*
*/

Identación ¶

En este caso tenemos que enfocarnos en la relación entra las distintas clases declaradas dentro de nuestra hoja de estilos.

Porque sí, en este caso, la anidación se toma como una especificación de relación entre las distintas clases.

Vamos a ver este código de ejemplo:

.foo { }

  .foo__bar { }

    .foo__baz { }

De este modo, podemos ver de un solo vistazo, que .foo__baz { } vive dentro de .foo__bar { } que a su vez vive dentro de .foo { }.

Nomenclatura ¶

Como en todo lenguaje, existen unas ciertas reglas de nomenclatura, vamos a ver las más importantes:

• Los nombres de clases deben estar escritas en inglés y en minúsculas.
• Si tenemos que poner espacios en el nombre de las clases, sustituir los mismos por guiones (ojo, no guiones bajos).
• Intentar nombrar de forma corta los selectores.

BEM ¶

Llegamos a la parte dura del artículo, el BEM.

Las siglas BEM hacen referencia a Block Element Modifier.

BEM no es más que una serie de reglas que nos ayudan a trabajar de una manera más eficiente y rápida, además de darnos una especie de ‘estándar’ que ayudará a otros programadores a entender nuestra hoja de estilos.

Quiero dejar claro que esto es simplemente una pequeña introducción a BEM, ya que BEM daría para un sólo artículo. O dos, o tres…

Tengamos en cuenta el significado de las siglas de BEM ya que hacen referencia explícita al modo de integrar las reglas de implementación:

• Tenemos el Bloque, que tiene una importancia mayor.
• El Elemento que es integrado dentro del bloque con una importancia menor al bloque.
• El modificador, que cambia el aspecto del bloque pero que no es considerado un elemento en sí. También tiene una importancia menor a la del bloque.

Teniendo esto en cuenta, imaginemos que tenemos un elemento con clase header, dentro integraremos un elemento, en este caso un listado (list) y que la cabecera (header) tiene un estilo diferente, por ejemplo black.

En este caso, la referencia al bloque principal se especificaría como cualquier otra clase: .header.

El elemento incluido dentro del bloque debe de esta precedido de un doble guion bajo: __list.

El modificador del bloque viene precedido por un doble guion: --dark.

La especificación de estas clases quedaría así:

/**
* Referencia al bloque principal
*/

.header {}

/**
* Referencia al elemento
*/

.header__list {}

/**
* Referencia al modificador enfocado al bloque
*/

.header--dark {}

Así, de un solo vistazo, podemos ver qué elemento está incluido dentro de qué bloque.

A su vez, podemos ver que alcance tiene el modificador, en este caso afecta al header.

Ampliando conocimientos ¶

Tal y como dijimos al principio, este artículo ha estado basado de uno de los episodios del podcast de la zona Premium de Daniel Primo.

¡No perdáis la oportunidad de escucharlo!

Además, contaros, que toda la información contenida en el artículo se ha basado en una guía de consejos CSS enfocada en consejos para construir un CSS más manejable, escalable y acorde con los estándares no escritos de las hojas de estilo.

Espero que hayáis disfrutado del artículo y ya sabéis:

¡Nos vemos en el siguiente fragmento de conocimiento, equipo!