CSS móvil primero: ¿Es hora de repensarlo?

La metodología de diseño móvil primero es excelente: se centra en lo que realmente le importa al usuario, está bien practicada y ha sido un patrón de diseño común durante años. Entonces, desarrollar tu CSS móvil primero también debería ser genial… ¿verdad?

Bueno, no necesariamente. El desarrollo CSS clásico para dispositivos móviles se basa en el principio de sobrescribir declaraciones de estilo: usted comienza su CSS con declaraciones de estilo predeterminadas y sobrescribe y/o agrega nuevos estilos a medida que agrega puntos de interrupción con min-width consultas de medios para ventanas gráficas más grandes (para obtener una buena descripción general, consulte “¿Qué es Mobile First CSS y por qué es genial?”). Pero todas esas excepciones crean complejidad e ineficiencia, lo que a su vez puede llevar a un mayor esfuerzo de prueba y a una base de código más difícil de mantener. Admítelo: ¿cuántos de nosotros queremos eso voluntariamente?

En sus propios proyectos, el CSS móvil primero puede ser la mejor herramienta para el trabajo, pero primero debe evaluar qué tan apropiado es a la luz del diseño visual y las interacciones del usuario en las que está trabajando. Para ayudarlo a comenzar, así es como abordo los factores que debe tener en cuenta y discutiré algunas soluciones alternativas si los dispositivos móviles primero no parecen adaptarse a su proyecto.

Ventajas del móvil primero

Algunas de las cosas que nos gustan del desarrollo CSS centrado en dispositivos móviles (y por qué ha sido la metodología de desarrollo de facto durante tanto tiempo) tienen mucho sentido:

Jerarquía de desarrollo. Una cosa que sin duda se obtiene de los dispositivos móviles primero es una buena jerarquía de desarrollo: simplemente se concentra en la vista móvil y comienza a desarrollar.

Probado y testado. Es una metodología probada que ha funcionado durante años por una razón: resuelve un problema muy bien.

Prioriza la vista móvil. La vista móvil es la lo más simple y posiblemente el más importante, ya que abarca todos los viajes de los usuarios clavey a menudo representa un mayor proporción de visitas de usuarios (dependiendo del proyecto).

Impide el desarrollo centrado en el escritorio. Como el desarrollo se realiza utilizando computadoras de escritorio, puede resultar tentador centrarse inicialmente en la vista de escritorio. Pero pensar en el móvil desde el principio evita que nos quedemos estancados más adelante; ¡Nadie quiere perder el tiempo adaptando un sitio centrado en computadoras de escritorio para que funcione en dispositivos móviles!

Desventajas de los dispositivos móviles primero

Establecer declaraciones de estilo y luego sobrescribirlas en puntos de interrupción más altos puede provocar ramificaciones no deseadas:

Más complejidad. Cuanto más arriba en la jerarquía de puntos de interrupción, más código innecesario heredará de los puntos de interrupción inferiores.

Mayor especificidad de CSS. Los estilos que han sido revertidos al valor predeterminado de su navegador en una declaración de nombre de clase ahora tienen una mayor especificidad. Esto puede ser un dolor de cabeza en proyectos grandes cuando desea mantener los selectores de CSS lo más simples posible.

Requiere más pruebas de regresión. Los cambios en el CSS en una vista inferior (como agregar un nuevo estilo) requieren que todos los puntos de interrupción superiores se sometan a una prueba de regresión.

El navegador no puede priorizar las descargas de CSS. En puntos de interrupción más amplios, el móvil clásico primero min-width Las consultas de medios no aprovechan la capacidad del navegador para descargar archivos CSS en orden de prioridad.

El problema de las anulaciones del valor de la propiedad

No hay nada inherentemente malo en sobrescribir valores; CSS fue diseñado para hacer precisamente eso. Aún así, heredar valores incorrectos no es útil y puede resultar engorroso e ineficiente. También puede conducir a una mayor especificidad de estilo cuando tiene que sobrescribir estilos para restablecerlos a sus valores predeterminados, algo que puede causar problemas más adelante, especialmente si está utilizando una combinación de CSS personalizado y clases de utilidad. No podremos usar una clase de utilidad para un estilo que se haya restablecido con una mayor especificidad.

Con esto en mente, estoy desarrollando CSS con un enfoque mucho más en los valores predeterminados en estos días. Dado que no hay un orden específico ni cadenas de valores específicos de los que realizar un seguimiento, esto me libera para desarrollar puntos de interrupción. simultáneamente. Me concentro en encontrar estilos comunes y aislar las excepciones específicas en rangos de consulta de medios cerrados (es decir, cualquier rango con un max-width colocar).

Este enfoque abre algunas oportunidades, ya que puede considerar cada punto de interrupción como un borrón y cuenta nueva. Si el diseño de un componente parece que debería basarse en Flexbox en todos los puntos de interrupción, está bien y se puede codificar en la hoja de estilos predeterminada. Pero si parece que Grid sería mucho mejor para pantallas grandes y Flexbox para dispositivos móviles, ambos se pueden hacer de forma totalmente independiente cuando el CSS se coloca en rangos cerrados de consulta de medios. Además, el desarrollo simultáneo requiere que usted tenga una buena comprensión de cualquier componente determinado en todos los puntos de interrupción desde el principio. Esto puede ayudar a que surjan problemas en el diseño en una fase más temprana del proceso de desarrollo. ¡No queremos quedarnos atrapados en una madriguera de conejo construyendo un componente complejo para dispositivos móviles y luego obtener los diseños para escritorio y descubrir que son igualmente complejos e incompatibles con el HTML que creamos para la vista móvil!

Aunque este enfoque no será adecuado para todos, te animo a que lo pruebes. Existen muchas herramientas para ayudar con el desarrollo concurrente, como Responsively App, Blisk y muchas otras.

Dicho esto, no creo que el orden en sí sea particularmente relevante. Si se siente cómodo centrándose en la vista móvil, comprende bien los requisitos de otros puntos de interrupción y prefiere trabajar en un dispositivo a la vez, siga el orden de desarrollo clásico. Lo importante es identificar estilos y excepciones comunes para poder colocarlos en la hoja de estilo correspondiente: ¡una especie de proceso manual de agitación de árboles! Personalmente, esto me resulta un poco más fácil cuando trabajo en un componente a través de puntos de interrupción, pero eso no es de ninguna manera un requisito.

Rangos de consultas de medios cerrados en la práctica

En el CSS clásico para dispositivos móviles sobrescribimos los estilos, pero podemos evitar esto usando rangos de consulta de medios. Para ilustrar la diferencia (estoy usando SCSS por brevedad), supongamos que hay tres diseños visuales:

• menor que 768
• desde 768 hasta menos de 1024
• 1024 y cualquier valor mayor

Tomemos un ejemplo simple donde un elemento a nivel de bloque tiene un valor predeterminado padding de “20px”, que se sobrescribe en la tableta para que sea “40px” y se vuelve a establecer en “20px” en el escritorio.

.my-block {
  padding: 20px;
  @media (min-width: 768px) {
    padding: 40px;
  }
  @media (min-width: 1024px) {
    padding: 20px;
  }
}

.my-block {
  padding: 20px;
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

The subtle difference is that the mobile-first example sets the default padding to “20px” and then overwrites it at each breakpoint, setting it three times in total. In contrast, the second example sets the default padding to “20px” and only overrides it at the relevant breakpoint where it isn’t the default value (in this instance, tablet is the exception).

The goal is to: 

• Only set styles when needed. 
• Not set them with the expectation of overwriting them later on, again and again. 

To this end, closed media query ranges are our best friend. If we need to make a change to any given view, we make it in the CSS media query range that applies to the specific breakpoint. We’ll be much less likely to introduce unwanted alterations, and our regression testing only needs to focus on the breakpoint we have actually edited. 

Taking the above example, if we find that .my-block spacing on desktop is already accounted for by the margin at that breakpoint, and since we want to remove the padding altogether, we could do this by setting the mobile padding in a closed media query range.

.my-block {
  @media (max-width: 767.98px) {
    padding: 20px;
  }
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

El navegador predeterminado padding para nuestro bloque es "0", por lo que en lugar de agregar una consulta de medios de escritorio y usar unset o “0” para el padding valor (que necesitaríamos con el móvil primero), podemos envolver el móvil padding en una consulta de medios cerrada (ya que ahora también es una excepción) para que no se detecte en puntos de interrupción más amplios. En el punto de interrupción del escritorio, no necesitaremos configurar ningún padding estilo, ya que queremos el valor predeterminado del navegador.

Agrupar versus separar el CSS

En el pasado, mantener el número de solicitudes al mínimo era muy importante debido al límite de solicitudes simultáneas del navegador (normalmente alrededor de seis). Como consecuencia, el uso de sprites de imágenes y paquetes de CSS era la norma, descargando todo el CSS de una sola vez, como una hoja de estilo con máxima prioridad.

Con HTTP/2 y HTTP/3 ahora en escena, la cantidad de solicitudes ya no es tan importante como solía ser. Esto nos permite separar el CSS en varios archivos mediante consulta de medios. El claro beneficio de esto es que el navegador ahora puede solicitar el CSS que necesita actualmente con mayor prioridad que el CSS que no necesita. Esto tiene más rendimiento y puede reducir el tiempo total de bloqueo de la representación de la página.

¿Qué versión de HTTP estás usando?

Para determinar qué versión de HTTP está utilizando, vaya a su sitio web y abra las herramientas de desarrollo de su navegador. A continuación, seleccione el Red pestaña y asegúrese de que Protocolo La columna es visible. Si "h2" aparece en la lista Protocolosignifica que se está utilizando HTTP/2.

Nota: para ver el protocolo en las herramientas de desarrollo de su navegador, vaya a Red pestaña, recarga tu página, haz clic derecho en cualquier encabezado de columna (por ejemplo, Nombre), y comprobar el Protocolo columna.

Además, si su sitio todavía usa HTTP/1... ¡¿POR QUÉ?!! ¿Qué estás esperando? Existe un excelente soporte de usuario para HTTP/2.

Dividiendo el CSS

Separar el CSS en archivos individuales es una tarea que vale la pena. Vincular los archivos CSS separados usando el correspondiente media El atributo permite al navegador identificar qué archivos se necesitan inmediatamente (porque bloquean el procesamiento) y cuáles se pueden aplazar. En base a esto, asigna a cada archivo una prioridad adecuada.

En el siguiente ejemplo de un sitio web visitado en un punto de interrupción móvil, podemos ver que el CSS móvil y predeterminado se cargan con la prioridad "Máxima", ya que actualmente son necesarios para representar la página. Los archivos CSS restantes (impresión, tableta y escritorio) aún se descargan en caso de que sean necesarios más adelante, pero con la prioridad "Mínima".

Con CSS incluidoel navegador tendrá que descargar el archivo CSS y analizarlo antes de que pueda comenzar la renderización.
Si bien, como se señaló, con el CSS separado en diferentes archivos vinculado y marcado con el correspondiente media atributo, el navegador puede priorizar los archivos que necesita actualmente. El uso de rangos de consulta de medios cerrados permite que el navegador haga esto en todos los anchos, a diferencia del clásico dispositivo móvil primero. min-width consultas, donde el navegador de escritorio tendría que descargar todo el CSS con la máxima prioridad. No podemos asumir que los usuarios de computadoras de escritorio siempre tendrán una conexión rápida. Por ejemplo, en muchas zonas rurales, las velocidades de conexión a Internet siguen siendo lentas.

Las consultas de medios y la cantidad de archivos CSS separados variarán de un proyecto a otro según los requisitos del proyecto, pero pueden ser similares al ejemplo siguiente.

Dependiendo de la estrategia de implementación del proyecto, un cambio en un archivo (mobile.csspor ejemplo) solo requeriría que el equipo de control de calidad realice una prueba de regresión en dispositivos en ese rango de consulta de medios específico. Compare eso con la perspectiva de implementar el paquete único site.css archivo, un enfoque que normalmente desencadenaría una prueba de regresión completa.

Continuando

La adopción de CSS para dispositivos móviles fue un hito realmente importante en el desarrollo web; Ha ayudado a los desarrolladores de front-end a centrarse en aplicaciones web móviles, en lugar de desarrollar sitios en computadoras de escritorio y luego intentar adaptarlos para que funcionen en otros dispositivos.

No creo que nadie quiera volver a ese modelo de desarrollo nuevamente, pero es importante que no perdamos de vista el problema que destacó: que las cosas pueden volverse complicadas y menos eficientes fácilmente si priorizamos un dispositivo en particular (cualquier dispositivo) sobre otros. Por esta razón, centrarse en el CSS por derecho propio, siempre teniendo en cuenta cuál es la configuración predeterminada y qué es una excepción, parece el siguiente paso natural. Empecé a notar pequeñas simplificaciones en mi propio CSS, así como en el de otros desarrolladores, y que el trabajo de prueba y mantenimiento también es un poco más simplificado y productivo.

En general, simplificar la creación de reglas CSS siempre que podamos es, en última instancia, un enfoque más limpio que andar en círculos de anulaciones. Pero cualquiera que sea la metodología que elija, debe adaptarse al proyecto. La tecnología móvil primero puede (o no) resultar ser la mejor opción para lo que implica, pero primero es necesario comprender sólidamente las compensaciones en las que se está metiendo.