CSS mobile-first : il est 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, est bien pratiquée et constitue un modèle de conception courant depuis des années. Donc développer du CSS pour mobile devrait 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 : vous commencez avec vos déclarations de style CSS par défaut et écrasez et/ou ajoutez de nouveaux styles à mesure que vous ajoutez des points d’arrêt. min-width requêtes multimédias pour des fenêtres d’affichage plus grandes (voir « Qu’est-ce que Mobile First CSS et pourquoi il est génial ? » pour un bon aperçu). Mais toutes ces exceptions créent de la complexité et des inefficacités, ce qui peut conduire à davantage de tests et à une base de code plus difficile à maintenir. Avouons-le : combien d’entre nous souhaitent cela volontairement ?

Pour vos propres projets, le CSS adapté aux mobiles reste peut-être le meilleur outil pour le travail, mais vous devez d’abord évaluer dans quelle mesure il est approprié à la lumière de votre conception visuelle et des interactions de l’utilisateur. Pour vous aider à démarrer, je vais vous expliquer les facteurs dont vous devez tenir compte et discuter de quelques solutions alternatives si la priorité au mobile ne semble pas adaptée à votre projet.

Avantages du mobile d’abord

Certaines des choses que j’aime 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) ont beaucoup de sens.

Hiérarchie du développement. Une chose que vous obtenez certainement du mobile en premier est une belle hiérarchie de développement : vous vous concentrez 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.

Préfère la vue mobile. La vue mobile est le plus simple et sans doute le plus important puisqu’il couvre tous les principaux parcours utilisateuret forme souvent un la majorité des visites des 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 d’abord sur la vue du bureau. Mais penser au mobile dès le départ évite de s’enliser plus tard. personne ne veut passer son temps à moderniser un site centré sur le bureau pour fonctionner sur des appareils mobiles !

Inconvénients du mobile d’abord

Définir des déclarations de style, puis remplacer des points d’arrêt plus élevés peut entraîner des conséquences inattendues :

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

Spécificité CSS plus élevée. Les styles dont la valeur par défaut du navigateur est restaurée dans la déclaration du nom de classe ont désormais plus de spécificité. Cela peut être un casse-tête pour les grands projets si vous souhaitez garder les sélecteurs CSS aussi simples que possible.

Nécessite davantage de tests de régression. Les modifications CSS dans une vue inférieure (comme 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. Dans les points d’arrêt plus larges, le mobile classique d’abord min-width les demandes multimédias n’utilisent pas la capacité du navigateur à télécharger les fichiers CSS par ordre de priorité.

La question de la valeur immobilière est primordiale

Il n’y a rien de mal en soi à écraser des valeurs ; C’est pour cela que CSS a été conçu. Cependant, hériter de mauvaises valeurs n’est pas utile et peut s’avérer fastidieux et inefficace. Cela peut également conduire à plus de spécificité dans les styles si vous devez écraser les styles pour les réinitialiser aux valeurs par défaut, ce qui peut causer des problèmes plus tard, surtout si vous utilisez une combinaison de classes CSS et utilitaires personnalisées. Nous ne pouvons pas utiliser une classe utilitaire sur un style initialisé avec plus de spécificité.

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

Cette approche ouvre certaines possibilités car vous pouvez visualiser chaque point d’arrêt comme une ardoise vierge. Si la disposition des composants semble devoir être basée sur Flexbox à tous les points d’arrêt, c’est très bien et peut être codée dans la feuille de style par défaut. Mais même s’il semble que Grid serait bien meilleur pour les grands écrans et Flexbox pour les mobiles, ils peuvent tous deux être réalisés de manière totalement indépendante avec CSS placé dans des plages de requêtes multimédias fermées. Le développement simultané nécessite également que vous ayez une bonne compréhension de n’importe quel composant à tous les points d’arrêt. Cela peut aider à mettre en évidence les problèmes de conception plus tôt dans le processus de développement. Nous ne voulons pas nous retrouver coincés dans le terrier de la création d’un composant complexe pour mobile, puis récupérer les conceptions de bureau et découvrir qu’elles sont tout aussi complexes et incompatibles avec le HTML créé pour la vue mobile !

Bien que cette approche ne convienne pas à tout le monde, je vous encourage à l’essayer. Il existe de nombreux outils qui facilitent le développement simultané, tels que Responsively App, Blisk et bien d’autres.

Cela dit, je ne trouve pas cette ordonnance particulièrement pertinente. Si vous aimez vous concentrer 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 tenez-vous-en à la file d’attente de développement classique. Il est important d’identifier les styles et les exceptions les plus courants afin de pouvoir les ajouter à la feuille de style appropriée – c’est une sorte de processus manuel d’arborescence ! Personnellement, je trouve cela un peu plus facile lorsque je travaille sur un composant de point d’arrêt, mais ce n’est en aucun cas une exigence.

Plages de requêtes multimédia fermées en pratique

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

• moins de 768
• De 768 à 1024
• 1024 et quelque chose de plus gros

Prenons un exemple simple où un élément au niveau du bloc a une valeur par défaut padding “20px” qui est remplacé par “40px” sur une tablette et réinitialisé à “20px” sur un ordinateur de bureau.

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

Paramètre du navigateur par défaut padding notre bloc est "0", donc au lieu d'ajouter une demande multimédia de bureau et d'utiliser unset ou pour "0". padding valeur (dont nous aurions besoin d'abord avec le mobile), nous pouvons emballer le mobile padding demande de média fermée (puisqu'il s'agit désormais également d'une exception) afin qu'elle ne soit pas trouvée dans des points d'arrêt plus larges. Nous n'avons pas besoin de le définir dans le point d'arrêt du bureau padding style comme nous voulons la valeur par défaut du navigateur.

Regroupement et séparation CSS

À l’époque, il était très important de maintenir le nombre de requêtes au minimum car le navigateur limitait le nombre de requêtes simultanées (généralement autour de six). En conséquence, le regroupement de sprites d’images et de CSS était courant, car tous les CSS étaient téléchargés en même temps, sous la forme d’une seule feuille de style ayant la priorité la plus élevée.

Avec HTTP/2 et HTTP/3 désormais utilisés, le nombre de requêtes n’est plus aussi important qu’avant. Cela nous permet de diviser le CSS en plusieurs fichiers à l'aide d'une requête multimédia. L'avantage évident 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 efficace et peut réduire le temps de blocage global du rendu des pages.

Quelle version de HTTP utilisez-vous ?

Pour déterminer quelle version de HTTP utiliser, accédez à votre site Web et ouvrez les outils de développement de votre navigateur. Ensuite, choisissez Réseau onglet et assurez-vous que Protocole la colonne est visible. Si "h2" est répertorié ci-dessous. Protocolesignifie que HTTP/2 est utilisé.

Note. Pour visualiser le protocole dans les outils de développement du navigateur, rendez-vous sur la page Réseau onglet, rechargez la page, faites un clic 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 ? HTTP/2 offre un excellent support utilisateur.

Fractionner le CSS

Séparer les CSS en fichiers individuels est une tâche intéressante. Lier des fichiers CSS séparés à l'aide des media L'attribut permet au navigateur d'identifier quels fichiers sont nécessaires immédiatement (car ils bloquent le rendu) et lesquels peuvent être différés. Sur cette base, il attribue une priorité appropriée à chaque fichier.

Dans l'exemple suivant d'un site Web visité à un point d'arrêt mobile, nous pouvons voir que les CSS mobiles et par défaut sont chargés avec la priorité « La plus élevée » car ils sont actuellement nécessaires au rendu de la page. Le reste des fichiers CSS (Impression, Tablette et Bureau) sera toujours téléchargé au cas où ils seraient nécessaires ultérieurement, mais avec la priorité « la plus basse ».

Ensemble CSS groupéle navigateur doit télécharger et analyser le fichier CSS avant le rendu.
Bien que, comme indiqué, avec CSS est divisé en différents fichiers liés et marqués avec des informations pertinentes media attribut, le navigateur peut hiérarchiser les fichiers dont il a actuellement besoin. Utiliser des plages de requêtes média fermées permet au navigateur de le faire sur toutes les largeurs, contrairement au principe mobile classique min-width requêtes où le navigateur de bureau doit télécharger tous les CSS avec la priorité la plus élevée. Nous ne pouvons pas supposer que les utilisateurs d’ordinateurs de bureau disposeront toujours d’une connexion rapide. Par exemple, les vitesses de connexion Internet sont encore lentes dans de nombreuses zones rurales.

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, un fichier est modifié (mobile.csspar exemple) obligerait l'équipe d'assurance qualité à tester par régression uniquement les appareils compris dans cette plage de requêtes multimédia particulière. Comparez cela avec la perspective de déployer un seul package site.css fichier qui exécute généralement un test de régression complet.

Passer à autre chose

L'introduction du CSS adapté aux mobiles a constitué une étape très 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 le bureau et d'essayer ensuite de les adapter pour fonctionner sur d'autres appareils.

Je ne pense pas que quiconque veuille revenir à ce modèle de développement, mais il est important que nous ne perdions pas de vue le problème qu'il a mis en évidence : les choses peuvent facilement devenir compliquées et moins efficaces si nous favorisons un appareil particulier (n'importe quel appareil) par rapport à d'autres. Pour cette raison, se concentrer séparément sur CSS, en gardant toujours à l’esprit ce qui est la valeur par défaut et quelle est l’exception, semble être une prochaine étape naturelle. J'ai commencé à remarquer de petites simplifications dans mon propre CSS et dans celui d'autres développeurs, et que le travail de test et de maintenance est également un peu plus facile et plus productif.

En général, simplifier la création de règles CSS autant que possible est en fin de compte une approche plus propre que de tourner en rond. Cependant, quelle que soit la méthodologie choisie, elle doit être adaptée au projet. Un téléphone mobile peut être le meilleur choix au début, mais vous devez d’abord comprendre clairement les compromis que vous faites.