La siguiente es una publicación invitada de Tom Genoni. Tom creó una extensión de Chrome de código abierto para analizar CSS. Dejaré que lo presente.
Es un nuevo proyecto web. Estás empezando desde cero. La parte delantera estará limpia y ordenada. Ha establecido sus valores predeterminados. Sus archivos CSS están organizados. ¡Tienes un sistema! Esta vez será diferente. ¿Qué podría salir mal?
Si esto le suena familiar, entonces sabrá cómo suele terminar: lenta e inevitablemente, el código comienza a hincharse y siente que el control se desvanece. Se vuelve complejo y entrelazado. Estás predominando los estilos, los nombres son inconsistentes, abundan los números mágicos y los trucos. El código antiguo es difícil de analizar, está mal documentado y buena suerte para que los nuevos compañeros de trabajo lo comprendan. Empiezan a aparecer errores. Maldita sea. Mejor simplemente ponle más CSS.
Decidido a evitar este destino, investigué técnicas de refactorización, mejores prácticas emergentes y, finalmente, construí CSS Dig. En esta publicación, destacaré tres áreas en las que CSS Dig puede ayudar y brindaré algunos consejos de refactorización.
Iniciar la auditoría
En la presentación de Nicolle Sullivan sobre su refactorización de Trulia, recomienda tomar capturas de pantalla de cada rincón y grieta de su sitio y agrupar los elementos de diseño para ver el universo de tamaños de fuente, botones, fondos, bordes, etc. Este ejercicio solo suele aparecer mucho. inconsistencias (y una buena cantidad de quejidos) y proporciona un punto de partida para la estandarización.
Después de darse cuenta de que, sí, tenemos demasiadas variaciones de botones, el siguiente paso es “grep sus estilos”: escudriñe su CSS de la misma manera y, a menudo, encontrará una amplia gama de propiedades y valores que son candidatos para la consolidación. Aquí es donde CSS Dig puede ayudar.
Después de instalar la extensión de Chrome, verá su icono en la esquina superior derecha de su navegador. Navegue a un sitio que le gustaría inspeccionar y haga clic en el icono. Algunas advertencias:
- En sitios con mucho CSS, y dependiendo de la velocidad de su conexión, CSS Dig puede tardar unos segundos en completarse.
- Los sitios con estrictas “Políticas de seguridad de contenido” pueden hacer que CSS Dig falle. Por ejemplo, facebook.com y github.com.
- CSS referenciado por
@importse ignora. Se considera una mala práctica y parece que la mayoría de los sitios ahora la evitan.
Acelera las cosas
Lo primero que verá es un cuadro de diálogo que enumera todos los archivos CSS y bloques de estilo que se encuentran en esa página. Tenga en cuenta que algunos archivos remotos, como los proveedores de fuentes, no son accesibles y se enumerarán como “Undiggable”. Puede deshabilitar elementos, como bibliotecas de terceros, que no desea incluir en el análisis, pero antes de “comenzar a excavar”, eche un vistazo a la lista. Reducir las solicitudes http es la regla de rendimiento número uno, por lo que combinar CSS en menos archivos es un buen lugar para comenzar.
Hay 10 solicitudes http para archivos CSS en la página de inicio de washingtonpost.com. ¿Se pueden combinar algunos de estos?
Una vez que haya elegido el CSS que le gustaría examinar, haga clic en “Comenzar a excavar” y se le presentará la pantalla principal de excavación de CSS. A la izquierda verá las propiedades y sus recuentos. Al hacer clic en ellos, se revelan las declaraciones reales utilizadas en el CSS. Y al hacer clic en las declaraciones individuales, se aíslan los conjuntos de reglas en la columna de la derecha.
Demasiados colores
Una de las primeras cosas que me gusta examinar son los colores. Los números altos aquí son a menudo el presagio de problemas en otras áreas. Hace un tiempo ejecuté CSS Dig en huffingtonpost.com. Desde entonces, han limpiado un poco las cosas, pero en ese momento estaban trabajando con esto:
Es bonito a su manera. Pero, ¿realmente necesitan todos esos rojos?
Los diferentes sitios web tienen diferentes necesidades y limitaciones, pero contrasta eso con los colores de apple.com:
Esto muestra un poco más de disciplina.
Debido a que CSS Dig le muestra la cantidad de veces que se usó un color, puede identificar rápidamente cuáles consolidar. Elija un azul dominante (o rojo o verde) y conviértalo en el predeterminado. Si está utilizando un preprocesador, cree variables y cúmplalas. Sus usuarios obtendrán una experiencia más consistente y será más fácil para usted mantenerla. Los mapas de Sass son geniales para esto.
$ui-color: (
brand : #0081BA,
brand-light : #9ACCE2,
brand-dark : #036,
bad-news : #C60C0C,
good-news : #97C70A
);Y luego hizo referencia a un color usando:
.foo {
color: map-get($ui-color, brand);
}Espaciado
Otras áreas de estandarización son los acolchados y los márgenes. No es raro tener una amplia variedad de valores, a veces en diferentes unidades, especialmente cuando diferentes equipos están trabajando en partes separadas de un sitio. Pero cuando los componentes tienen que mezclarse y combinarse, las inconsistencias pueden hacerse evidentes rápidamente.
Una forma de abordar esto es estableciendo una cuadrícula de espaciado global que se aplique a todos los elementos (con la excepción ocasional). En la biblioteca de UI de Optimizely usamos una unidad de espaciado, actualmente de 10px, y todo el espaciado de los componentes se basa en eso. Esto ayuda a excluir los “números mágicos” pero le da cierta discreción al autor de CSS.
Por ejemplo, el siguiente código:
.foo {
padding: spacer(1);
margin: spacer(1.5) 0;
}compila para:
.foo {
padding: 10px;
margin: 15px 0;
}utilizando:
@function spacer($value) {
@if ($value * 2) % 1 != 0 {
@warn 'Spacer value must be a multiple of 0.5';
@return 'Spacer value must be a multiple of 0.5';
} @else {
@return $spacer-unit * $value;
}
}Si nuestra función espaciadora ve un valor que no es un incremento de 0.5, devuelve un error. No hay nada que impida que el autor utilice un número codificado, pero las excepciones se pueden discutir en una revisión del código. Descubrí que esto crea con frecuencia una armonía fortuita entre los componentes.
Guerras de especificidad
Cuando Sass estaba ganando popularidad, no era raro ver a los desarrolladores intentar igualar la estructura anidada del HTML que estaban diseñando. Parece una buena idea. Lo intenté. Pero resulta que eso crea todo tipo de complicaciones y ahora está mal visto.
Entre los dolores que exacerba está la larga lucha con la especificidad de CSS. Anular selectores largos en un esfuerzo por reutilizar un componente altamente específico es una experiencia confusa y molesta, que a menudo resulta en más selectores y (jadeo) !important reglas y códigos que esperas no tener que explicar a nadie.
Selectores largos de nytimes.com.
En la pestaña Selectores de un informe CSS Dig, verá todos los selectores enumerados con opciones para ordenar por longitud y especificidad. Estos se calculan utilizando la Calculadora de especificidad de Keegan Street. Esto ayudará a identificar posibles bombas de tiempo de selección y, con suerte, comenzará el proceso de hacer que los estilos sean menos anidados, más rentables y más fáciles de mantener. También recomiendo usar el generador de gráficos de especificidad CSS para obtener una vista panorámica de su código.
Sigue adelante
Si después de echar un vistazo a su propio código descubre que desea hacer una refactorización más profunda, aquí hay algunos pasos más a considerar.
- Elija un nombre de código corto para el refactor. Esto ayuda a darle importancia al proyecto y, lo que es más importante, proporciona una forma de espacios de nombres para nuevas clases. En Optimizely estamos usando
lego-como prefijo para todas las clases (sí, lo sé, nombre súper original) pero ha sido invaluable para proporcionar una clara separación entre las clases nuevas y antiguas. - Adopte un enfoque modular y orientado a objetos, como BassCSS, SMACSS o la próxima actualización de Harry Roberts de su Inuitcss. Esto ha reducido en gran medida la cantidad de código nuevo que escribimos y ha acelerado considerablemente el tiempo de desarrollo.
- Utilice un linter (como CSS lint o SCSS-lint). Esto aplicará automáticamente una larga lista de estandarizaciones de código comunes, manteniendo su código limpio y consistente.
Contribuir
El código fuente de CSS Dig está disponible en GitHub. Sus sugerencias, solicitudes e informes de errores son bienvenidos.
Además, trabajo en Optimizely, échale un vistazo. Estamos trabajando en algunas cosas interesantes.