CSS Mobile-First : est-il temps de repenser ?

La méthodologie de conception axée sur le mobile est excellente, elle se concentre sur ce qui compte vraiment pour l’utilisateur, elle est bien pratiquée et constitue un modèle de conception populaire depuis des années. Donc développer du CSS axé sur le mobile doit aussi être génial… n’est-ce pas ?

Eh bien, pas nécessairement. Le développement CSS classique axé sur les mobiles est basé sur le principe de l’écrasement des déclarations de style : votre CSS commence par les déclarations de style par défaut, et remplace et/ou ajoute de nouveaux styles à mesure que vous ajoutez des points d’arrêt avec min-width Requêtes multimédias pour des fenêtres d’affichage plus grandes (pour un bon aperçu, voir « Qu’est-ce que Mobile First CSS et pourquoi est-il génial ? »). Mais toutes ces exceptions créent de la complexité et de l’inefficacité, ce qui peut à son tour conduire à des efforts de test accrus et à une base de code difficile à maintenir. Admettez-le – combien d’entre nous le souhaiteraient volontiers ?

Dans vos propres projets, le CSS mobile peut être le meilleur outil pour le travail, mais vous devez d’abord évaluer son adéquation à la lumière de la conception visuelle et des interactions utilisateur avec lesquelles vous travaillez. Pour vous aider à démarrer, voici comment aborder les facteurs que vous devez surveiller, et je discuterai de quelques solutions de contournement si la priorité mobile ne semble pas être une bonne solution pour votre projet.

Avantages du téléphone mobile avant tout

Certaines choses à apprécier dans le développement CSS axé sur les mobiles – et pourquoi il s’agit d’une méthodologie de développement de facto depuis si longtemps – sont tout à fait logiques :

Hiérarchie de développement. Une chose que vous obtenez sans aucun doute du mobile en premier est une bonne hiérarchie de développement : concentrez-vous simplement sur la vue mobile et commencez à développer.

Essayé et testé. Il s’agit d’une méthodologie éprouvée qui a fonctionné pendant des années pour une raison : elle résout très bien le problème.

Donne la priorité à la visualisation mobile. La vue mobile est Plus simple Sans doute le plus important, car c’est Inclut tous les principaux parcours utilisateursouvent représenté par A Pourcentage plus élevé de visites d’utilisateurs (selon le projet).

Empêche le développement centré sur le bureau. Étant donné que le développement s’effectue à l’aide d’ordinateurs de bureau, il peut être tentant de se concentrer initialement sur l’affichage sur ordinateur. Mais penser au mobile dès le début nous évite de trébucher plus tard ; Personne ne veut passer son temps à mettre à jour un site centré sur un ordinateur pour fonctionner sur des appareils mobiles !

Inconvénients du téléphone mobile d’abord

Définir des déclarations de style, puis les écraser à des points d’arrêt plus élevés peut conduire à des résultats indésirables :

Plus de complexité. Plus vous montez dans la hiérarchie des points d’arrêt, plus vous héritez de code inutile des points d’arrêt inférieurs.

Spécificité CSS plus élevée. Les styles qui ont été rétablis à la valeur par défaut du navigateur dans la déclaration du nom de classe bénéficient désormais d’une confidentialité plus élevée. Cela peut être un casse-tête dans les grands projets lorsque vous souhaitez garder les sélecteurs CSS aussi simples que possible.

Nécessite davantage de tests de régression. Les modifications apportées au CSS dans la vue inférieure (telles que l’ajout d’un nouveau style) nécessitent des tests de régression sur tous les points d’arrêt supérieurs.

Le navigateur ne peut pas donner la priorité aux téléchargements CSS. Aux arrêts plus larges, le mobile classique d’abord min-width Les requêtes multimédias ne profitent pas de la capacité du navigateur à télécharger les fichiers CSS par ordre de priorité.

Le problème de la surévaluation immobilière

Il n’y a rien de mal en soi à écraser des valeurs ; CSS est conçu pour cela. Cependant, hériter de valeurs invalides n’est pas utile et peut s’avérer fastidieux et inefficace. Cela peut également augmenter la spécificité du style lorsque vous devez écraser les styles pour les réinitialiser à leurs valeurs par défaut, ce qui peut causer des problèmes plus tard, surtout si vous utilisez une combinaison de classes CSS et d’utilitaires personnalisés. Nous ne pourrons pas utiliser de classe utilitaire pour un modèle remappé avec une spécificité plus élevée.

Dans cet esprit, je développe du CSS en me concentrant davantage sur les valeurs par défaut ces jours-ci. Puisqu’il n’y a pas d’ordre spécifique ni de chaînes de valeurs spécifiques à suivre, cela me libère du développement de points d’arrêt. ensemble. Je me concentre sur la recherche de modèles communs et l’isolement d’exceptions spécifiques dans des étendues de requêtes multimédias fermées (c’est-à-dire n’importe quelle étendue avec max-width embauche).

Cette approche ouvre certaines opportunités, car vous pouvez considérer chaque point d’arrêt comme une page vierge. Si la disposition des composants semble dépendre de Flexbox à tous les points d’arrêt, ce n’est pas grave et peut être codée dans la feuille de style par défaut. Mais s’il semble que Grid serait bien meilleur pour les grands écrans et Flexbox pour les mobiles, cela peut être fait de manière totalement indépendante en plaçant CSS dans des portées de requêtes multimédias fermées. Le développement simultané nécessite également que vous ayez une bonne compréhension à l’avance d’un composant donné à tous les points d’arrêt. Cela peut aider à faire ressortir les problèmes de conception dès le début du processus de développement. Nous ne voulons pas nous retrouver coincés à créer un composant complexe pour mobile, puis obtenir des conceptions de bureau et découvrir qu’elles sont tout aussi complexes et incompatibles avec le HTML que nous avons créé pour la visualisation mobile !

Même si cette approche ne fonctionnera pas pour tout le monde, je vous encourage à l’essayer. Il existe de nombreux outils disponibles pour faciliter le développement simultané, tels que Responsively App, Blisk et bien d’autres.

Cela dit, je ne pense pas que la même chose soit particulièrement importante. Si vous êtes à l’aise en vous concentrant sur la vue mobile, avez une bonne compréhension des exigences des autres points d’arrêt et préférez travailler sur un appareil à la fois, alors respectez par tous les moyens l’ordre de développement classique. L’important est d’identifier les modèles communs et les exceptions afin de pouvoir les insérer dans la feuille de style appropriée – une sorte de processus manuel d’arborescence ! Personnellement, je trouve cela un peu plus facile lorsque l’on travaille sur un composant via des points d’arrêt, mais ce n’est en aucun cas une obligation.

Portées fermées des requêtes multimédias en pratique

Dans le CSS classique axé sur les mobiles, nous écrasons les styles, mais nous pouvons éviter cela en utilisant des portées de requêtes multimédias. Pour illustrer la différence (j’utilise SCSS par souci de concision), supposons qu’il existe trois conceptions visuelles :

• Plus petit que 768
• De 768 à moins de 1024
• 1024 et tout ce qui est supérieur

Prenons un exemple simple où un élément de niveau bloc a une valeur par défaut padding “20px”, qui sur tablette est remplacé par “40px” et est redéfini sur “20px” sur ordinateur.

.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;
  }
}

Navigateur par défaut padding Pour notre bloc, il s'agit de « 0 », donc au lieu d'ajouter et d'utiliser la requête multimédia de bureau unset Ou "0" pour padding valeur (dont nous avons d'abord besoin avec le téléphone mobile), nous pouvons encapsuler le téléphone mobile padding Dans une requête multimédia fermée (puisqu'il s'agit désormais également d'une exception), elle ne sera donc pas récupérée à des points d'arrêt plus larges. Au point d'arrêt du bureau, nous n'aurons besoin de définir aucun d'entre eux padding style, car nous voulons la valeur par défaut du navigateur.

Agrégation vs découplage CSS

Dans le passé, il était très important de limiter les requêtes au minimum en raison du nombre maximal de requêtes simultanées du navigateur (généralement autour de six). En conséquence, l'utilisation d'animations et de regroupements CSS était la norme, tous les fichiers CSS étant téléchargés en même temps, sous la forme d'une seule feuille de style avec la plus haute priorité.

Avec HTTP/2 et HTTP/3 désormais en place, le nombre de requêtes n’est plus aussi important qu’avant. Cela nous permet de séparer CSS en plusieurs fichiers par requête multimédia. L'avantage évident de ceci est que le navigateur peut désormais demander le CSS dont il a actuellement besoin avec une priorité plus élevée que le CSS dont il n'a pas besoin. Ceci est plus performant et peut réduire la durée globale pendant laquelle la page est bloquée.

Quelle version de HTTP utilisez-vous ?

Pour déterminer quelle version de HTTP vous utilisez, accédez à votre site Web et ouvrez les outils de développement du navigateur. Ensuite, sélectionnez réseau Tabulez et vérifiez protocole La colonne est visible. Si "h2" est inséré dans protocoleCela signifie que HTTP/2 est utilisé.

Remarque : Pour afficher le protocole dans les outils de développement de votre navigateur, accédez à réseau rechargez votre page, puis cliquez avec le bouton droit sur n'importe quel en-tête de colonne (par exemple, nom), et vérifiez protocole colonne.

De plus, si votre site utilise toujours HTTP/1... pourquoi ?!! Qu'est-ce que tu attends ? Il existe un excellent support utilisateur pour HTTP/2.

Fractionnement CSS

Séparer les CSS en fichiers individuels est une tâche intéressante. Liez des fichiers CSS séparés à l'aide d'un media Cet attribut permet au navigateur de déterminer quels fichiers sont nécessaires immédiatement (car ils bloquent la visualisation) et quels fichiers peuvent être différés. En conséquence, il attribue à chaque fichier une priorité appropriée.

Dans l'exemple suivant d'un site Web visité sur un point d'arrêt mobile, nous pouvons voir que les CSS mobile et par défaut sont chargés avec la priorité "la plus élevée", car ils sont actuellement requis pour afficher la page. Les fichiers CSS restants (impression, tablette et ordinateur de bureau) sont toujours téléchargés au cas où ils seraient nécessaires ultérieurement, mais avec une priorité « inférieure ».

avec CSS groupéle navigateur devra télécharger et analyser le fichier CSS avant que le rendu puisse commencer.
Alors que, comme indiqué, avec CSS a été séparé en différents fichiers Lié et codé avec des éléments associés media Attribut, le navigateur peut prioriser les fichiers dont il a actuellement besoin. L'utilisation de portées de requêtes multimédias fermées permet au navigateur de le faire à tous les niveaux de présentation, plutôt que d'utiliser d'abord le mobile classique. min-width requêtes, où le navigateur de bureau doit télécharger tous les fichiers CSS avec la priorité la plus élevée. Nous ne pouvons pas supposer que les utilisateurs d’ordinateurs de bureau disposent toujours d’une connexion rapide. Par exemple, dans de nombreuses zones rurales, les vitesses de connexion Internet sont encore lentes.

Les requêtes multimédias et le nombre de fichiers CSS distincts varient d'un projet à l'autre en fonction des exigences du projet, mais peuvent ressembler à l'exemple ci-dessous.

En fonction de la stratégie de déploiement du projet, il se transformera en un seul fichier (mobile.csspar exemple) nécessiterait uniquement que l'équipe d'assurance qualité effectue des tests de régression sur les appareils dans le cadre de cette requête multimédia spécifique. Comparez cela à la probabilité de déploiement d'un seul package site.css fichier, une approche qui aboutirait généralement à un test de régression complet.

Poursuivre

Comprendre le CSS mobile-first a été une étape importante dans le développement Web ; Cela a aidé les développeurs front-end à se concentrer sur les applications Web mobiles, plutôt que de développer des sites sur ordinateur, puis d'essayer de les mettre à jour pour qu'ils fonctionnent sur d'autres appareils.

Je ne pense pas que quiconque veuille revenir à ce modèle de développement, mais il est important de ne pas perdre de vue le problème qu'il souligne : les choses peuvent facilement devenir complexes et moins efficaces si nous donnons la priorité à un appareil particulier - n'importe quel appareil - par rapport aux autres. Pour cette raison, se concentrer sur CSS lui-même, en gardant toujours à l’esprit quelle est la valeur par défaut et quelle est l’exception, semble être la prochaine étape naturelle. J'ai commencé à remarquer de petites simplifications dans mon propre CSS, ainsi que dans celui d'autres développeurs, et mon travail de test et de maintenance est également devenu beaucoup plus simple et plus productif.

En général, simplifier la création de règles CSS chaque fois que nous le pouvons est en fin de compte une approche plus propre que de tourner en rond avec des remplacements. Mais quelle que soit la méthodologie que vous choisissez, elle doit correspondre au projet. Le mobile d'abord peut s'avérer ou non la meilleure option à cet égard, mais vous devez d'abord bien comprendre les compromis dans lesquels vous vous engagez.