Genérico First CSS: Nuevo pensamiento en Mobile First

Creo que es seguro decir que el diseño web receptivo de Ethan Marcotte fue una revelación bienvenida para los desarrolladores web de todo el mundo. Desencadenó toda una nueva ola de pensamiento de diseño y nuevas y maravillosas técnicas de front-end. El reinado de los sitios web m dot, a menudo despreciados, también había terminado. En la misma era y casi tan influyente fue la metodología Mobile First de Luke Wroblewski, una mejora sólida que se basó en los impresionantes cimientos de Marcotte.

Estas técnicas son la base de la vida de la mayoría de los desarrolladores web, y nos han servido bien, pero, por desgracia, los tiempos cambian y los desarrolladores iteran constantemente. A medida que aumentamos la eficiencia de nuestros métodos y los requisitos del proyecto se vuelven más complejos, surgen nuevas frustraciones.

El viaje hacia lo genérico primero

No puedo precisar exactamente qué me hizo cambiar la forma en que escribo mi CSS porque realmente fue una progresión natural para mí que sucedió casi inconscientemente. Mirando hacia atrás, creo que fue más un subproducto del entorno de desarrollo en el que estaba trabajando. El equipo con el que trabajé tenía un buen flujo de trabajo SCSS con una pequeña combinación ingeniosa para agregar fácilmente puntos de interrupción dentro de nuestras declaraciones CSS. Probablemente utilice una técnica similar.

Esta pequeña y maravillosa combinación SCSS de repente hizo que fuera fácil escribir consultas de medios súper granulares. Tome un bloque biográfico hipotético que se parezca a esto:

 .bio { display: block; width: 100%; background-color: #ece9e9; padding: 20px; margin: 20px 0; @include media('>=small') { max-width: 400px; background-color: white; margin: 20px auto; } @include media('>=medium') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

Figura 1. Móvil típico primero con consultas de medios en cascada

Esto funciona bien: he escrito mucho CSS como este en el pasado. Sin embargo, un día me di cuenta de que sobrescribir las declaraciones CSS a medida que aumentaba el ancho del dispositivo simplemente no tenía sentido. ¿Por qué declarar una propiedad CSS para que solo se sobrescriba en la siguiente declaración?

Esto es lo que me llevó a comenzar a escribir consultas de medios compartimentadas en oposición al enfoque más común de consultas de medios que caen en cascada hacia arriba (o hacia abajo) como el ejemplo en la Fig.1.

En lugar de escribir consultas de medios que caen en cascada hacia arriba con aumentos en el tamaño de la pantalla, comencé a crear consultas de medios específicas que encapsularían estilos en los anchos de pantalla deseados. La mezcla de consulta de medios realmente se destacaría aquí. Ahora mis consultas de medios SCSS comienzan a verse así:

 .bio { display: block; width: 100%; padding: 20px; margin: 20px 0; @include media('>=small', ' < medium') { max-width: 400px; margin: 20px auto; } @include media('>=medium', ' < large') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large', ' < huge') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

Figura 2. Un ejemplo de consultas de medios compartimentadas

Este nuevo enfoque me pareció más intuitivo, redujo la necesidad de restablecer los estilos desde el punto de interrupción anterior y estaba haciendo que el CSS fuera más fácil de leer. Más importante aún, estaba haciendo que las consultas de los medios se documentaran a sí mismas de una manera más significativa.

Sin embargo, todavía no estaba 100% satisfecho con lo anterior. Parecía que todavía había un problema importante que superar.

El problema con el móvil primero

El problema con los dispositivos móviles primero es que, por definición, lo más probable es que tenga que anular los estilos de dispositivos móviles primero en consultas de medios posteriores. Esto se siente como un anti-patrón.

Entonces, para mí, la respuesta era obvia: llevemos la idea de la compartimentación de consultas de medios a su conclusión lógica; también compartimentaremos los estilos específicos de dispositivos móviles en sus propias consultas de medios. Lo sé, lo sé, esto va en contra de la convención común que hemos aprendido a lo largo de los años. “Mobile First” es tan omnipresente que generalmente es una de las preguntas de “habilidades” que hará un gerente de contratación. Así que seguramente cualquier alternativa debe ser incorrecta, ¿no es así? Por lo general, esta es la parte en la que la gente sacude la cabeza mientras dice móvil primero una y otra vez.

Bien, entonces vamos a romper el primer dogma móvil y compartimentar todos nuestros estilos en las consultas de medios relevantes. Lo que nos queda ahora son estilos genéricos puros declarados en un selector de CSS, con todos los demás estilos específicos del dispositivo encapsulados en consultas de medios que solo se aplican a las dimensiones de pantalla relevantes. Ahora tenemos Generic First CSS :

 .bio { display: block; width: 100%; @include media('>=0', ' < small') { padding: 20px; margin: 20px 0; } @include media('>=small', ' < medium') { max-width: 400px; margin: 20px auto; } @include media('>=medium', ' < large') { max-width: 600px; padding: 30px; margin: 30px auto; } @include media('>=large', ' < huge') { max-width: 800px; padding: 40px; margin: 40px auto; } @include media('>=huge') { max-width: 1000px; padding: 50px; margin: 50px auto; } }

Fig. 3. Un ejemplo de Generic First CSS

Sí, hay un poco más de consultas de medios, sin embargo, veo esto como un beneficio, cualquier desarrollador ahora puede mirar este CSS y ver exactamente qué estilos se aplican en todos y cada uno de los tamaños de pantalla sin la sobrecarga cognitiva de tener que separar los medios. especificidad de la consulta.

¡Esto puede ser excelente para las personas que no están familiarizadas con el código base o incluso con el futuro!

Cuándo no compartimentar

Todavía hay momentos en los que la compartimentación de consultas de medios es una carga y, en algunos casos, una consulta de medios antigua >= está bien. Recuerde, todo lo que intentamos hacer es evitar sobrescribir propiedades.

Felicidad de la herramienta de desarrollo

Una de las principales consecuencias no deseadas de escribir Generic First CSS compartimentado es la experiencia que obtendrá del panel de estilo de sus herramientas de desarrollador. Sin la cascada de consulta de medios, ahora tendrá una visión general más clara de los estilos que se aplican. No tendrá un panel de estilo lleno de declaraciones tachadas de reglas de consulta de medios sobrescritas. ¡Se acabó el ruido! Esto, para mí, es uno de los mayores beneficios de la técnica Generic First CSS. Aporta un poco más de cordura a la experiencia de depuración de CSS, y esto vale su peso en oro. Agradéceme después.

Implicaciones de rendimiento

Entonces, todos estos beneficios de Generic First CSS comienzan a sonar bastante bien, pero creo que hay una última pregunta clave que creo que debe abordarse. Es sobre el tema de la optimización del rendimiento. Todavía no lo sé con certeza, pero tengo el presentimiento de que las consultas de medios completamente compartimentadas pueden tener un ligero beneficio en el rendimiento.

Los navegadores realizan una tarea de representación llamada cálculo de estilo computado . Es la forma en que los navegadores calculan qué estilos deben aplicarse a un elemento en un momento dado. Esta tarea siempre se realiza en la carga de la página inicial, pero también se puede realizar si el contenido de la página cambia o si se realizan otras acciones del navegador. Cualquier aumento que pueda dar a la velocidad del proceso será excelente para la carga inicial de la página y podría tener un efecto combinado en el ciclo de vida de las páginas de su sitio web.

Entonces, volviendo al primer CSS genérico: ¿Hay algún problema de rendimiento relacionado con el navegador que tiene que resolver la especificidad de CSS de una multitud de consultas de medios en cascada?

Para responder a eso, he ideado un caso de prueba que se puede usar para medir los beneficios de la velocidad o, de hecho, los inconvenientes.

El caso de prueba

El caso de prueba se compone de una página HTML básica que genera un bloque "biográfico" 5000 veces, el marcado es el mismo para cada bloque, pero las clases son ligeramente diferentes (diferenciador numérico), el CSS para este bloque también se genera 5000 veces , siendo los nombres de las clases lo único que difiere. El CSS generado se canaliza a través de una herramienta llamada CSS MQPacker, esto ayuda a reducir drásticamente el tamaño del archivo de CSS que utiliza muchas consultas de medios en línea al combinar todas las instancias separadas de una consulta de medios específica en una sola. Es una gran herramienta que probablemente se beneficiará la mayoría de las bases de código CSS modernas: lo he usado como una herramienta cli independiente a través de una tarea npm en el paquete de proyectos de prueba.json, también puede usarlo como un complemento postcss, ¡lo cual es agradable y conveniente!

El primer caso de prueba es un ejemplo de consultas de medios en cascada en dispositivos móviles, el segundo caso de prueba es una primera variante genérica compartimentada del CSS. El CSS para estos casos es un poco detallado y probablemente podría escribirse en términos mucho más concisos, pero en realidad solo sirve como un ejemplo aproximado para probar el argumento.

La prueba se ejecutó 20 veces para cada variación de CSS en el escritorio de Google Chrome v70, no es un conjunto masivo de datos, pero es suficiente para darme una idea aproximada de la ganancia/pérdida de rendimiento.

Las métricas de prueba que he elegido usar son:

• Tiempo total de carga de la página
  Una métrica básica para comprobar el tiempo de carga de la página utilizando los marcadores de la API de rendimiento al principio de <head> y al final de <body>
• El estilo Recalcular
  Tiempo desde el panel de rendimiento de las herramientas de desarrollo.
• Representación general de la página
  Tiempo desde el panel de rendimiento de las herramientas de desarrollo.

Tabla de resultados (todos los tiempos en milisegundos)

Figura 6. 20 ejecuciones de prueba que miden las métricas clave de carga/renderización de CSS móvil primero frente a CSS genérico primero.

Desde mi conjunto de datos ciertamente pequeño, parece que mi sospecha inicial puede ser correcta. En promedio, veo que la tarea de recálculo de estilo tarda 42 ms menos, lo que representa un aumento de velocidad del 7,6 % y, por lo tanto, el tiempo de renderizado general también disminuye. La diferencia no es alucinante, pero es una mejora. No creo que el conjunto de datos sea lo suficientemente grande como para ser 100% concluyente y el caso de prueba es un poco poco realista, pero estoy muy contento de no ver una degradación del rendimiento.

Me interesaría mucho ver la primera metodología genérica aplicada a una base de código existente en el mundo real que se ha escrito en la forma móvil primero: las métricas antes y después serían mucho más realistas para la práctica diaria.

Y si alguien tiene sugerencias sobre cómo automatizar esta prueba en un conjunto más amplio de iteraciones, ¡hágamelo saber en los comentarios! Me imagino que debe haber una herramienta que pueda hacer esto.

Conclusión

Para recapitular sobre los beneficios de esta nueva metodología de desarrollo...

• CSS que hace exactamente lo previsto, sin dudas;
• Consultas de medios de autodocumentación;
• Una mejor experiencia de herramientas de desarrollo;
• Páginas que se procesan más rápido.

Me gustaría pensar que no soy la única persona que defiende la escritura de CSS en este estilo. Si ya ha adoptado la primera mentalidad genérica, ¡hurra! Pero si no, creo que te gustarán mucho los beneficios que trae. Personalmente, me he beneficiado mucho de la experiencia ordenada de las herramientas de desarrollo, que en sí misma será muy positiva para muchos desarrolladores. la naturaleza de autodocumentación de esta forma de escribir sus consultas de medios también tendrá beneficios para usted y para el equipo en general (si tiene uno). Y, por último, estos beneficios no le costarán nada en términos de rendimiento y, de hecho, ¡se ha demostrado que tienen ganancias de velocidad marginales!

última palabra

Al igual que todas las metodologías de desarrollo, puede que no sea para todos, pero he caído en Generic First CSS de forma bastante natural, ahora lo veo como una forma valiosa de trabajar que me brinda todos los beneficios de mobile first con algunas nuevas adiciones positivas que hacen el duro trabajo del desarrollo front-end que poco sea más fácil.

Recursos

Informe de caso de prueba

Si desea iniciar el caso de prueba y probarlo usted mismo, puede encontrarlo en GitHub, me encantaría ver algunos informes de otros.

Herramientas

• CSS MQ Packer
• Incluir medios