Tag: SASS

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…).

 

Ventajas de usar SASS aunque no sepas SASS

Pongamos que por algún motivo no quieres o no puedes  aprender SCSS (o LESS, o SASS, etc. son basicámente lo mismo). No vas a utilizar anidaciones, mixins, variables ni ninguna otra de las ventajas que ofrece y quieres seguir trabajando con CSS “plano”.
Aun así, tendrías que considerar usar SASS en tu flujo de trabajo por las siguientes razones:

Trabajarías exactamente igual

Los archivos .css son archivos validos para SCSS. No tendrías que aprender ninguna sintaxis nueva y puedes seguir usando los archivos que ya utilizas.

Mejorarías  mucho la carga con archivos css modulares

Pongamos que cargas en tu web el ubicuo Bootstrap, el archivo .css de tu pagina y dos o tres .css externos, ademas de los @import con las fuentes que utilices de Google Fonts. Todos esos archivos hay que cargarlos por separado antes del render de la pagina y ralentizan mucho la fase más importante de la carga de una web. Si los incluyes como @imports de SASS en una hoja .scss y luego compilas, tendrás un único archivo .css (y una única llamada al servidor con todo lo que necesitas.

Te olvidas de los fallbacks

Si compilas con GULP en vez de con el propio SASS, ademas de compilar mucho más rápido,  puedes incluir el plugin autoprefixer que añade los -webkit-,  -moz-,  -msfilter- etc. necesarios para visualizarse correctamente en todos los navegadores que le configures. Escribes el código de una forma mas rápida y limpia y te olvidas de tener que andar consultando caniuse.com e incluyendo manualmente los prefijos, que es un coñazo. Utiliza los dotas del propio caniuse.com y puedes incluso configurarlo cronológicamente. Yo lo configuro para todos los navegadores de los últimos 7 años.

Avisa de los errores.

Trabajando con .css puedes olvidar un punto y coma, o equivocarte en la ortografía, y no te darás cuenta hasta que visites la parte de la web afectada, SASS  no te permite compilar un archivo si contiene errores, avisándote de su localización.

En fin, no necesitas aprender SASS/SCSS para empezar a utilizarlo y aprovechar muchas de sus ventajas. Luego empezaras a utilizar variables, anidaciones, etc. y te preguntaras como podías trabajar antes sin el.

Usando GULP

Estoy usando GULP como gestor de tareas y es una maravilla. Es como tener un becario (que dios y los becarios me perdonen…) para encargarle tareas repetitivas.

Antes usaba SASS para compilar archivos .scss, pero los hace uno a uno, y cuando tenia que compilar un modulo que empleaban 30 o 40 archivos .css se hacia lento esperar a que acabara. GULP carga todos los archivos en memoria antes de trabajar con ellos y es mucho mas rápido. Además, me permite utilizar plugins como autoprefixer, que añade los prefijos para asegurar compatibilidad con los navegadores que le configures, incluso cronológicamente, yo lo tengo configurado para que me ponga los prefijos necesarios hasta 7 años de antigüedad. Así puedo escribir código mucho más rápido sin tenerme que preocupar de los moz- y los webkit-

Tambien lo uso para concatenar y minificar los .js, de esta forma acabo generando un único .css y un único .js para toda la pagina web y carga como un tiro.

Al ser la sintaxis de sass como la de .css puedo introducir en la compilacion css ajenos , como los de los reproductores de video, ahorrandome archivos y llamadas al servidor.

También sirve muy bien para realizar tareas repetitivas que no pueden ser conseguidas con un simple batch. Tuve un caso similar al siguiente en el trabajo, localizar una serie de archivos html que hacían referencia a una imagen map.png que no estaba en su carpeta /img, generando un error 404.

Podría haber localizado los .html con un buscador por contenido, pero luego habría tenido que mirar carpeta por carpeta si el map.png se hallaba ahí, hablamos de unos 400 archivos html de los cuales la mitad podían estar en esa situación.

Os pongo el codigo utilizado en el script GULP que utilicé para localizarlos, con una explicación paso a paso de lo que hace:

 var gulp = require('gulp');  //carga gulp
 var contains = require('gulp-contains');  //carga plugin para buscar textos
 var fs = require('fs');  //carga plugin para buscar archivos
 var counter = 0;  //variable contador de archivos
 gulp.task('busca', function() {  //abre proceso 'busca'     
 gulp.src('es/**/trivia.txt')    //carga archivos sobre los que trabajar, todos  los html de todas las subcarpetas en la carpeta /es
 .pipe(contains({   //añade plugin contains
     search: 'map.png', //busca esta cadena
     onFound: function(string, file, cb) { //cuando la encuentre....
     try {
         fs.accessSync(file.path.slice(0, -10) + "img/map.png"); //...a partir del path del archivo, busca el archivo map.png
     } catch (e) { //si no lo encuentra...  
         counter ++;//actualiza el contador...
         console.log(counter +":"+ file.path.slice(0, -9)); //...y muestra la ruta  en la consola ("restando" map.png)
         return false }  //cierro  fs.accessSync                 
     return false;} //cierro search           
     }))    //cierro  contains
    .pipe(gulp.dest(function(file) {return file.base;})) });  //path de destino de los archivos *
gulp.task('default', ['check']);  //arranca al hacer gulp en el terminal

* en este caso, no seria necesario porque no realizo ningún proceso con los archivos, pero GULP lo necesita para funcionar correctamente, sino, detiene la búsqueda en los 16 primeros.