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 (2): Smacss

¿Otra?

No se si llamarla “otra”, porque es compatible con BEM y pueden trabajar juntas. BEM es más un sistema de nomenclatura (y uso) para evitar problemas de especificidad y herencia  y Smacss es un sistema organizativo de las propias hojas de estilo para facilitar el escalar proyectos, es un poco mas antigua.

¿Y de que va?

La base de Smacss es separar las clases css por su funcionalidad según las siguientes categorías:Base: Podriamos entenderlo como un reset ampliado. Aquí se definen solo los tags, sin clases ni id´s.

Layout: Aquí va todo lo referente a la estructura de la pagina, las secciones, etc.

Module: Partes reutilizables de la web cuyo css debería ser escrito pensando en su independencia.

State: Todas las propiedades relativas a estados, desplegado, activo, apagado, colapsado, etc.

Theme: Unicamente el aspecto visual, fuentes, colores., etc.

Es un esquema flexible, una web podría no necesitar un theme, o podría necesitar un .scss añadido (fonts.scss por ejemplo) si necesitara retoques según el idioma elegido.
Idealmente, estas partes deberían estar en archivos independientes, con los antiguos import de css esto penalizaría la carga pero con sass no hay problemas.

¿Como se escribe?

El autor no pontifica ni se mete mucho con ese tema,  sino que aconseja usar prefijos para las distintas partes, él usa los prefijos .l- para layout, .is- para los estados (que tiene mucho sentido: .is-active) etc.
Las partes relacionadas con un modulo usaran su nombre como prefijo para saber a cual hay que aplicarlas: .example-header
Además, hace hincapié en reducir la “profundidad de aplicación”, esto es, que las clases no dependan de una estructura html determinada.
En este ejemplo:

body.article > #main > #content > #intro > p > strong { }

Vemos una profundidad de aplicación de 6 niveles (aunque hicieramos “.article strong” serian los mismos niveles) cuanta menor sea la profundidad, menos dependerá de una estructura determinada y mas fácil sera mover elementos de una parte a otra. Esto llevado al extremo seria usar las clases directamente, sin herencia, y nos acercariamos a BEM…

Por ejemplo esto tambien seria caca para Smacss:

#sidebar div h3

Porque necesita una estructura determinada y lo correcto seria algo como

.modulo h3

No importa tener que añadir mas clases al html si es para aumentar la flexibilidad.

Vale, quiere reducir la herencia al mínimo ¿y que opina de la especificidad?

Pongamos que tenemos esto:

.pod {
 width: 100%;
 }
 .pod input[type=text] {
 width: 50%;
 }

Y necesitamos que cuando esté en un #sidebar el ancho  del input sea de 100%. Lo primero que nos pide el cuerpo es añadir un selector padre así:

#sidebar .pod input[type=text] {
width: 100%;
}
 Smacss dice “¡No! ¡Caca! ¡Frontender malo!”
Eso añade especificidad al input, si necesitaramos reutilizar la clase .pod dentro de un sidebar con un nuevo ancho de su input, de nuevo habrá que superar la especificidad que hemos puesto añadiendo un selector mas o metiendo un temido !important.
Para evitarlo Smacss propone añadir una nueva clase derivada de .pod (smacss las llama subclases) quedaria así.
.pod {
 width: 100%;
 }
 .pod-short input[type=text] {
 width: 50%;
 }
.pod-callout {
 width: 200px;
 }
 .pod-callout input[type=text] {
 width: 180px;
 }

Y se aplicarian así:

<div class="pod pod-short">...</div>
<div class="pod pod-callout">...</div>

Recordemos que BEM supera los problemas de especificidad usando solamente clases y nunca usando selectores, así, todas las clases se encuentran al mismo nivel y deja de existir la especificidad, una clase machaca a la anterior y chimpun.

 ¿Y a ti te mola?

Si. Esta muy bien lo de separar las clases por su funcionalidad.
Pero me rechina un poco cuando habla de añadir clases para conseguir diseños, y de nuevo, habla de problemas que pueden o no pueden serlo, o pueden resolverse de otras maneras.
Por ejemplo para evitar ligar demasiado el css a una estructura html propone añadir clases, y esa es otra forma de ligar html y css y me genera dudas…
Igual  puedes tener que rediseñar un blog con unos contenidos que ya tienen una maquetación determinada y no puedes añadir clases…
Por ejemplo no es lo mismo cuando el front end developer tiene libre acceso a las plantillas html para poner y quitar clases  que cuando no se tiene acceso (o es limitado) al código.

¿Donde saber más?

El librito del autor está en:

Se lee rápido y hay muchas cosas interesantes.