Depurando tu CSS con las dev tools de Chrome

En fin, ese css tan hermoso y limpio en origen ha pasado varias guerras, nacimientos y muertes en el DOM y ahora es un empastre inescrutable de miles de lineas donde nadie se atreve a quitar nada.
Pero hay herramientas para ayudarte a ponerlo en vereda.

https://cssstats.com/

graficoespec

Analiza tu css y te devuelve un completo informe con la cantidad de colores, fuentes, gráficos de especificidad, etc. Todas las estadísticas sobre tu CSS necesarias para tener un primer vistazo de la situación y un punto de referencia con el que comparar el trabajo una vez terminado.
Ademas puedes cotillear informes de sitios populares.

Interpretar el gráfico de especificidad daria para articulo completo pero baste saber que debería ser lo mas lo mas plano y bajito posible, señal de que no hay id’s, ni !important’s, ni selectores “largos”, etc.

No obstante, la información de fuentes y colores ya es muy útil para ir localizando código repetido e innecesario,

Ya tenemos unas estadísticas y hay que localizar el css no utilizado. Podemos ayudarnos de la función coverage, del inspector de chrome, nos vamos a la ventana (more tools> coverage)  y pulsamos el botón de iniciar grabación.
Nos aparecerá los CSS y JS de la pagina web con una barra indicando que porcentaje del archivo es usado ademas de otra información. Podemos pinchar sobre el nombre del fichero css para ver su fuente en la ventana sources, donde se nos marca con barras rojas/verdes las clases no usadas/usadas.

Inicialmente se nos marcan en rojo tanto  las clases CSS como las funciones JS que no se utilizan, como algunas dependen de cambios en el DOM, conforme van siendo utilizadas al navegar se van marcando en verde.

clean

Una vez finalizada la navegación, tendremos una primera aproximación de las clases que podemos borrar, podemos hacerlo ahi mismo en la ventana de sources y luego hacer copipaste, o bien usar la funcion overrides para guardar una copia en disco de las ediciones que hacemos.

Para activar overrides nos vamos a su pestaña en la ventana izquierda de sources (es posible que tengamos que pulsar >> para verla) y si es la primera vez que la activamos, nos pedirá un directorio donde almacenar los cambios.

A partir de ahora, podemos hacer los cambios necesarios en el css (como borrar las clases pintadas en rojo por no ser usadas) y al hacer control+s se nos guardará la copia del css en el directorio indicado. Es más, al recargar la pagina, mientras tengamos activado el checkbox de “Enable local overrides” se usara el css guardado en local en vez del css del servidor.

Ojo con esto, no lo dejemos activado sin darnos cuenta al acabar la faena o nos puede confundir. Tenemos alguna ayuda visual para evitarlo, arriba, en el nombre del archivo, nos aparece una bolita morada para indicar que es un archivo sobrescrito en local, y un asterisco si hay cambios sin guardar

Captura de pantalla 2019-02-25 a las 14.12.23

También tendremos un ojo puesto en la ventana computed del inspector, ahí nos indicara cuantas clases estamos chafando en cada elemento, cifra que trataremos de mantener al mínimo.

Una vez limpio el css es buena idea es pasar el CSS a SASS, si es que no lo usamos ya, (que seguro que no, porque si no usar estas herramientas no tendría mucho sentido), para ello tenemos varios servicios en linea como http://sebastianpontow.de/css2compass/ que está muy bien y nos permite bastantes opciones.

Incluso si no fuéramos a utilizar SASS (que deberiamos si o si), nos ayudará a comprender que clases dependen de otras y como están anidadas en el CSSDOM.

Ya tenemos el CSS limpio de clases no usadas y ordenado.  El siguiente paso seria ajustar su nomenclatura con un poco de sentido y coherencia según alguna de las metodologias que hemos visto.

A mi me gusta marcar las clases que dependen de otras al estilo de BEM, pero me encanta usar la herencia, y uso tags semanticos, por lo que no hago una herencia paralela basada en la nomenclatura como exige el sistema, solo tomo de BEM la nomenclatura de clases.

Por ultimo seria conveniente dividirlo  minimamente al estilo de SMACSS en modulos según su función al gusto de cada uno, usualmente yo parto de:  reset (inicializacion y normalize) , composicion (layout y maquetacion, margenes..) y aspecto (colores, fondos, fuentes…).

 

Metodologias CSS (y 5): Conclusiones

Vemos que los esquemas de lo que clásicamente se han considerado  “buenas practicas” de css resulta que no lo son siempre ni para todo el mundo y hay sangrientas  peleas  entre hermanos del frontend acerca de si es mejor añadir una clase al html  o poner un selector en el css.

 Dios nos dio el poder de resolver un problema con css de mil formas distintas y se nos ha ido de las manos 🙂

Hemos visto una forma de estructurar el css (Smacss) y tres metodologias para la nomenclatura/organización de las clases (BEM, DRY, Atomic).
Estas metodologias sirven para solucionar con distintas estrategias  una serie de problemas que da el css al escalar, basicamente:

  • Guerras de especificidad
  • Herencias no deseadas
  • Ligazon html-css

Desde mi punto de vista, si no tienes estos problemas, tu proyecto es pequeño, etc. quizá es mejor no utilizar ninguna y seguir las practicas clásicas, ya que cada metodología tiene sus inconvenientes acarreados. Planificando bien no debería uno tener ningún problema de los anteriores, es más, la herencia y especificidad pueden jugar a tu favor.

Otra cosa es un proyecto con mil y pico archivos scss y 94 developers como he leido que tiene Linkedin, eso no hay planificación previa que lo organice y ahi si que traerá ventajas adoptar un sistema de nomenclatura u otro.
¿Mejor añadir clases al html o selectores al css? ¿Tengo libre acceso al html? ¿lo tengo al css?¿Voy a usar preprocesadores? ¿somos un equipo pequeño o grande?
En función de las respuestas se elige uno, o ninguno y se adopta un mix de soluciones.

¿Tengo que compartir un único css entre muchos sitios con distintos htmls?
Quizá ATOMIC

¿Tengo que compartir un único html entre muchos sitios con distintos css sin acceso al html?
Quizá DRY

¿Tengo que mantener un sitio muy complejo con varios developers trabajando en el html/css ?
Quiza BEM

Todos los sistemas son un punto de compromiso distinto entre las distintas opciones que nos planteamos al hacer un css y las dos principales vias de ligar css y html:

-Clases semánticas acerca del contenido (.autor_bio), el CSS depende del HTML.
El HTML es “reestilable” sin tocarlo, pero el css no se puede reutilizar. (EJ: CSS Zen Garden)

-Clases semanticas acerca del diseño (.white_panel”), el HTML depende del CSS. 
El CSS es reutilizable pero el html no se puede reestilar sin tocarlo. (Bootstrap)

Aquí esta la experiencia de un hombre que conforme el proyecto creia se encontró con el problema que yo temo de BEM (entre otros), hay que hacer cientos de clases muy parecidas, acabo así:
https://medium.engineering/simple-style-sheets-c3b588867899

After more thought and some experimentation, we found a middle way: get rid of modifiers, leave non-atomic CSS only for low-level interface components (buttons, links, lists, and so on) and have the rest use these very specific atomic classes.

Al final esta es la via, tomar de cada sistema lo que a uno le interese cuando le interese. Nos podemos quedar con la jerarquia de css paralela que propone BEM, con el uso avanzado de grupos de DRY, con las utility class de Atomic y montar un sistema mixto adaptado a lo que se necesite.

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”?

No, BEM dice que no.
Dice que anidar selectores  es malo, porque es impredecible, añade especificidad, causa muchos problemas y mejor no usarlo. Impide reutilizar bloques de una parte a otra, y gran parte del trabajo de css es resetear y sobrescribir valores heredados. Además complica el trabajo cuando varios developers trabajan sobre el mismo proyecto.
BEM propone eliminar la anidacion de los selectores 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 jerarquia de selectores natural de css a una jerarquia 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?

Depende, soy un clasico, 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.

Pero claro, a uno se le revuelven las tripas cuando le proponen renunciar a la jerarquia de selecotres 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 jerarquia “de maquetacion” 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 pseudoDOM 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 jerarquia 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 y comodo aprovechar la jerarquia en un proyecto mas pequeño o liderado por una sola persona.

Y también puedo imaginar un mundo alternativo  horrible donde la jerarquia 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.