CSS móvil primero: ¿es hora de repensar?

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. Así que tu desarrollo móvil CSS también debería ser fantástico… ¿verdad?

Bueno, no es necesario. El desarrollo CSS clásico para dispositivos móviles se basa en el principio de sobrescribir declaraciones de estilo: comienza su CSS con declaraciones de estilo predeterminadas y sobrescribe y/o agrega nuevos estilos a medida que agrega puntos de interrupción. 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é colapsa?”). Pero todas estas excepciones crean complejidad e ineficiencias, 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?

En sus propios proyectos, el CSS móvil primero puede seguir siendo la mejor herramienta para el trabajo, pero primero debe evaluar qué tan apropiado es dado el diseño visual y la interacción del usuario en el que está trabajando. Para ayudarlo a comenzar, así es como abordaré los factores a considerar y discutiré algunas soluciones alternativas si la tecnología móvil primero no es adecuada para su proyecto.

Ventajas del móvil primero

Algunas de las cosas que le encantarán del desarrollo de CSS para dispositivos móviles (y por qué ha sido la metodología de desarrollo de facto durante tanto tiempo) tienen mucho sentido:

Jerarquía del desarrollo. Una cosa que definitivamente obtienes de los dispositivos móviles es una buena jerarquía de desarrollo: simplemente te concentras en la vista móvil y desarrollas.

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

Prioriza la vista móvil. Hay una vista móvil el mas simple Y probablemente el más importante como este. Cubre todos los recorridos principales de los clientesy a menudo cuenta un Mayor porcentaje de visitas de usuarios (depende del proyecto).

Impide el desarrollo centrado en el escritorio. Dado que el desarrollo se realiza utilizando computadoras de escritorio, puede resultar tentador centrarse inicialmente en la vista de escritorio. Pero pensar en el móvil en primer lugar evita que nos quedemos estancados más adelante; ¡Nadie quiere pasar tiempo trabajando en un sitio centrado en computadoras de escritorio en dispositivos móviles!

Desventajas del móvil primero

Establecer declaraciones de estilo y luego sobrescribirlas en puntos superiores puede provocar resultados no deseados:

más dificultad. Cuanto más alto llegue en la jerarquía de puntos de interrupción, más código innecesario heredará de los puntos de interrupción inferiores.

Especificación CSS superior. Los estilos que volvieron al valor predeterminado del navegador en la declaración del 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 de CSS en la vista secundaria (como agregar nuevos estilos) requieren pruebas de regresión en todos los puntos de interrupción superiores.

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 solicitudes de medios no aprovechan la capacidad del navegador para descargar archivos CSS en orden de prioridad.

El problema del valor inmobiliario

No hay nada inherentemente malo en sobrescribir valores; Para eso se creó CSS. Sin embargo, heredar valores incorrectos no es útil y puede resultar engorroso e ineficiente. Esto también puede conducir a una mayor especificidad de estilo, donde hay que reescribir los estilos para devolverlos a los valores predeterminados, lo que puede causar problemas más adelante, especialmente si se utiliza una combinación de CSS personalizado y clases de utilidad. No podremos utilizar una clase de utilidad para un estilo sobrecargado con una especificación superior.

Con eso en mente, he estado desarrollando CSS con un enfoque más en los valores predeterminados en estos días. Como no hay un orden específico ni una cadena de valor específica a seguir, eso me libera para desarrollar puntos de interrupción. simultáneamente. Me concentro en encontrar estilos comunes y aislar excepciones específicas en rangos de consulta de medios cerrados (es decir, cualquier rango max-width colocar).

Este enfoque abre algunas posibilidades porque puede considerar cada punto de interrupción como una hoja de papel en blanco. Si el diseño del 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 estilo predeterminada. Pero si parece que Grid será mucho mejor para pantallas grandes y Flexbox para dispositivos móviles, ambos se pueden hacer de forma completamente independiente cuando el CSS se coloca en medios cerrados dentro del rango de solicitud. Además, el desarrollo concurrente requiere que tenga un buen conocimiento de cualquier componente determinado en todos los puntos de interrupción. Esto puede ayudar a que surjan problemas en el diseño en una fase más temprana del proceso de desarrollo. ¡No queremos caer en la trampa de diseñar un componente complejo para dispositivos móviles, luego tomar el diseño para escritorio y descubrir que son igual de complejos e incompatibles con el HTML que creamos para la vista móvil!

Si bien este enfoque no funcionará para todos, te animo a que lo pruebes. Hay toneladas de herramientas que lo ayudarán a desarrollarse simultáneamente, como Responsively App, Blisk y muchas más.

Dicho esto, no creo que el orden sea particularmente relevante. Si se siente cómodo concentrándose en la vista móvil, comprende los requisitos de otros puntos de interrupción y prefiere trabajar en un dispositivo a la vez, entonces siga el orden de desarrollo clásico. La clave es identificar los estilos comunes y las excepciones para poder colocarlos en la hoja de estilo adecuada: ¡una especie de proceso manual de agitación de árboles! Personalmente, lo encuentro un poco más fácil cuando trabajo en un componente en puntos de interrupción, pero de ninguna manera es un requisito.

Rango de consulta de medios cerrado en la práctica

En el CSS clásico para dispositivos móviles, anulamos los estilos, pero podemos evitarlo utilizando rangos de consulta de medios. Para ilustrar la diferencia (usaré SCSS por brevedad), digamos que hay tres diseños visuales:

• Menos de 768
• De 768 a 1024
• 1024 y mayores

Tomemos un ejemplo simple donde un elemento a nivel de bloque tiene un valor predeterminado padding “20px”, que se reescribe como “40px” en una tableta y se establece en “20px” en un 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;
  }
}

Navegador predeterminado padding Debido a que nuestro bloque es "0", en lugar de agregar y usar la solicitud de medios de escritorio unset o "0" para eso padding valor (que necesitaremos primero con el móvil), podemos desplazar el móvil padding en una solicitud de medios cerrada (ya que ahora también es una excepción), por lo que no se escribirá en puntos de interrupción más amplios. En el punto de interrupción del escritorio, no necesitaremos instalar nada. padding Diseñe como queramos el valor predeterminado del navegador.

Envolver versus separar 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 resultado, el uso de sprites de imágenes y ajuste de CSS se convirtió en la norma, y ​​todo el CSS se descargaba en un solo paso como una única hoja de estilo con la máxima prioridad.

Con HTTP/2 y HTTP/3 ahora en escena, la cantidad de solicitudes ya no es tan grande como solía ser. Esto nos permite dividir CSS en varios archivos con solicitudes de medios. El beneficio obvio de esto es que el navegador ahora puede solicitar el CSS que necesita actualmente con mayor prioridad que el CSS que no necesita. Esto es más eficiente y puede reducir el tiempo total de bloqueo de la página.

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

Cualquiera que sea la versión de HTTP que esté utilizando, vaya a su sitio web y abra las herramientas de desarrollo de su navegador. A continuación, seleccione red Tabulador y asegúrese de que protocolo La columna es visible. Si se especifica "h2" a continuación protocoloEsto significa que se utiliza HTTP/2.

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

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

Dividir CSS

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

En el siguiente ejemplo de un sitio web visitado en un punto de interrupción móvil, vemos que el CSS móvil y predeterminado se cargan con la prioridad "más alta" porque actualmente son necesarios para representar la página. Los archivos CSS restantes (impresión, tableta y escritorio) aún se descargarán si los necesita más adelante, pero con la prioridad "más baja".

junto con CSS empaquetadoEl navegador deberá descargar y analizar el archivo CSS antes de que pueda comenzar la renderización.
Aunque, como se mencionó, juntos CSS se divide en diferentes archivos Relacionado y marcado como relevante media atributo, el navegador puede priorizar qué archivos necesita actualmente. El uso de un rango de consulta de medios cerrado permite que el navegador haga esto en todos los anchos, a diferencia del móvil clásico. min-width Solicitudes en las que el navegador de escritorio deberá descargar todos los CSS con la máxima prioridad. No podemos dar por sentado que los usuarios de escritorio siempre tengan una conexión rápida. Por ejemplo, en muchas zonas rurales las velocidades de conexión a Internet siguen siendo lentas.

Los requisitos de medios y la cantidad de archivos CSS individuales variarán de un proyecto a otro según los requisitos del proyecto, pero pueden parecerse al ejemplo siguiente.

Dependiendo de la estrategia de implementación del proyecto, un cambio a un solo archivo (mobile.cssPor ejemplo) solo requiere que el equipo de control de calidad realice pruebas de regresión en dispositivos dentro de un rango específico de solicitudes de medios. Compare esto con la perspectiva de un diseño empaquetado único. site.css archivo, un enfoque que normalmente daría como resultado una prueba de regresión completa.

moverse

La adopción de CSS para dispositivos móviles fue de hecho un hito en el desarrollo web; Ayudó a los desarrolladores de front-end a centrarse en aplicaciones web móviles en lugar de desarrollar sitios para escritorio y luego intentar refactorizarlos para que funcionen en otros dispositivos.

No creo que nadie quiera volver a ese modelo de desarrollo, pero es importante no perder de vista el problema que destacó: que las cosas pueden volverse confusas y menos eficientes fácilmente si favorecemos un dispositivo en particular (cualquier dispositivo) sobre otros. Por esta razón, centrarse en CSS en sí, considerando siempre cuál es la configuración predeterminada y cuál es la excepción, es el siguiente paso natural. Empecé a notar pequeñas simplificaciones en mi propio CSS, así como en otros desarrolladores, y que las pruebas y el mantenimiento también son un poco más ágiles y productivos.

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 sea cual sea la metodología que elijas, debe ser adecuada para el proyecto. El móvil primero puede ser o no la mejor opción, pero primero es necesario comprender las compensaciones que se están realizando.