Phone : 06 64 18 40 00 - Email : contact@multiverseconcept.com
Méthodologie mobile-first
⇒ Article original : Mobile-First CSS: Is It Time for a Rethink? par Patrick Clancey
Translated with the permission of A List Apart and the author[s].
La méthodologie de conception « mobile-first » est excellente : elle se concentre sur ce qui compte vraiment pour l’utilisateur, elle est bien pratiquée et c’est un modèle de conception courant depuis des années. Par conséquent, le développement de votre CSS en fonction du mobile devrait également être une bonne chose… n’est-ce pas ?
Eh bien, pas nécessairement. Le développement CSS classique de type « mobile-first » repose sur le principe de l’écrasement des déclarations de style : vous commencez votre CSS avec des déclarations de style par défaut, et vous écrasez et/ou ajoutez de nouveaux styles au fur et à mesure que vous ajoutez des points d’arrêt avec des requêtes média min-width pour des fenêtres d’affichage plus grandes (pour un bon aperçu, voir « What is Mobile First CSS and Why Does It Rock ?« ). Mais toutes ces exceptions créent de la complexité et de l’inefficacité, ce qui peut entraîner une augmentation des efforts de test et une base de code plus difficile à maintenir. Admettez-le, combien d’entre nous souhaitent volontairement cela ?
Sur vos propres projets, le CSS mobile-first peut encore être le meilleur outil pour le travail, mais vous devez d’abord évaluer dans quelle mesure il est approprié à la lumière de la conception visuelle et des interactions utilisateur sur lesquelles vous travaillez. Pour vous aider à démarrer, voici comment j’aborde les facteurs à surveiller, et j’évoquerai d’autres solutions si le principe du mobile first ne semble pas convenir à votre projet.
Avantages du développement mobile-first
Certains des avantages du développement CSS en mode « mobile first » – et la raison pour laquelle il s’agit de la méthodologie de développement de facto depuis si longtemps – sont très logiques :
La hiérarchie du développement. Une chose que vous obtenez indubitablement du mobile-first est une belle hiérarchie de développement – vous vous concentrez simplement sur la vue mobile et vous développez.
Testé et éprouvé. Il s’agit d’une méthodologie éprouvée qui fonctionne depuis des années pour une raison : elle résout très bien un problème.
Priorité à l’affichage mobile. La vue mobile est la plus simple et sans doute la plus importante, car elle englobe tous les parcours clés de l’utilisateur et représente souvent une plus grande proportion des visites des utilisateurs (selon le projet).
Empêche le développement centré sur l’ordinateur de bureau. Le développement étant effectué sur des ordinateurs de bureau, il peut être tentant de se concentrer initialement sur la vue du bureau. Mais penser au mobile dès le départ nous évite de nous retrouver bloqués par la suite ; personne ne veut passer son temps à réadapter un site centré sur l’ordinateur de bureau pour qu’il fonctionne sur des appareils mobiles !
Inconvénients du principe "mobile first"
Le fait de définir des déclarations de style puis de les écraser à des points de rupture plus élevés peut entraîner des ramifications indésirables :
Plus de complexité. Plus vous montez dans la hiérarchie des points d’arrêt, plus vous héritez de code inutile provenant des points d’arrêt inférieurs.
Une plus grande spécificité CSS. Les styles qui ont été ramenés à leur valeur par défaut dans le navigateur dans une déclaration de nom de classe ont maintenant une spécificité plus élevée. Cela peut être un casse-tête sur les grands projets lorsque vous voulez garder les sélecteurs CSS aussi simples que possible.
Nécessite davantage de tests de régression. Les modifications apportées au CSS à un point de vue inférieur (comme l’ajout d’un nouveau style) exigent que tous les points de rupture supérieurs soient testés par régression.
Le navigateur ne peut pas donner la priorité aux téléchargements CSS. Aux points de rupture plus larges, les requêtes média classiques de type « mobile first min-width » n’exploitent pas la capacité du navigateur à télécharger les fichiers CSS par ordre de priorité.
Le problème de l'écrasement des valeurs des propriétés
Il n’y a rien de mal en soi à écraser des valeurs ; CSS a été conçu pour cela. Néanmoins, l’héritage de valeurs incorrectes n’est pas utile et peut être lourd et inefficace. Cela peut également entraîner une spécificité accrue des styles lorsque vous devez écraser les styles pour les réinitialiser à leurs valeurs par défaut, ce qui peut poser des problèmes par la suite, surtout si vous utilisez une combinaison de CSS personnalisés et de classes utilitaires. Nous ne pourrons pas utiliser une classe utilitaire pour un style qui a été réinitialisé avec une spécificité plus élevée.
En gardant cela à l’esprit, je développe beaucoup plus de CSS en me concentrant sur les valeurs par défaut ces derniers temps. Comme il n’y a pas d’ordre spécifique, ni de chaînes de valeurs spécifiques à suivre, cela me permet de développer des points d’arrêt simultanément. Je me concentre sur la recherche de styles communs et l’isolement des exceptions spécifiques dans les plages de requêtes média fermées (c’est-à-dire toute plage avec une max-width définie).
Cette approche ouvre certaines possibilités, car vous pouvez considérer chaque point d’arrêt comme une table rase. Si la mise en page d’un composant semble devoir être basée sur Flexbox à tous les points d’arrêt, elle est parfaite et peut être codée dans la feuille de style par défaut. Mais s’il semble que la grille serait bien mieux adaptée aux grands écrans et que Flexbox conviendrait mieux aux mobiles, ces deux options peuvent être réalisées de manière totalement indépendante lorsque le CSS est placé dans des plages de requêtes média fermées. En outre, le développement simultané exige que vous ayez une bonne compréhension de tout composant donné dans tous les points de rupture dès le départ. Cela peut aider à faire apparaître les problèmes de conception plus tôt dans le processus de développement. Nous ne voulons pas nous retrouver coincés au fond d’un terrier à construire un composant complexe pour le mobile, puis obtenir les conceptions pour le bureau et découvrir qu’elles sont tout aussi complexes et incompatibles avec le HTML que nous avons 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 pour faciliter le développement simultané, comme Responsively App, Blisk et bien d’autres.
Cela dit, je ne pense pas que la commande elle-même soit particulièrement pertinente. Si vous êtes à l’aise avec l’idée de vous concentrer sur la vue mobile, que vous comprenez bien les exigences des autres points d’arrêt et que vous préférez travailler sur un seul appareil à la fois, alors vous pouvez vous en tenir à l’ordre de développement classique. L’important est d’identifier les styles et exceptions communs afin de les placer dans la feuille de style correspondante – une sorte de processus manuel de secouage d’arbre ! Personnellement, je trouve cela un peu plus facile lorsque je travaille sur un composant à travers des points d’arrêt, mais ce n’est en aucun cas une obligation.
Les plages de requêtes média fermées en pratique
Dans le CSS mobile-first classique, nous écrasons les styles, mais nous pouvons éviter cela en utilisant des plages de requêtes média. Pour illustrer la différence (j’utilise SCSS par souci de concision), supposons qu’il existe trois conceptions visuelles :
- inférieur à 768
- de 768 à moins de 1024
- 1024 et tout ce qui est supérieur
padding par défaut de « 20px », qui est écrasé sur la tablette pour être « 40px » et remis à « 20px » sur le bureau.Mobile-first min-width classique
.my-block {
padding: 20px;
@media (min-width: 768px) {
padding: 40px;
}
@media (min-width: 1024px) {
padding: 20px;
}
}Plage de requêtes média fermée
.my-block {
padding: 20px;
@media (min-width: 768px) and
(max-width: 1023.98px) {
padding: 40px;
}
}
La différence subtile est que l’exemple mobile-first définit le padding par défaut à « 20px » et l’écrase ensuite à chaque point d’arrêt, le définissant trois fois au total. En revanche, le deuxième exemple fixe le padding par défaut à « 20px » et ne l’écrase qu’au point d’arrêt pertinent où il n’est pas la valeur par défaut (dans ce cas, la tablette est l’exception).L’objectif est le suivant :
- Ne définir les styles que lorsque cela est nécessaire.
- Ne pas les définir dans l’espoir de les écraser plus tard, encore et encore.
.my-block sur un ordinateur de bureau est déjà pris en compte par la marge au niveau de ce point d’arrêt, et que nous voulons supprimer complètement le remplissage, nous pouvons le faire en définissant le padding mobile dans une plage de requête de média fermée.
.my-block {
@media (max-width: 767.98px) {
padding: 20px;
}
@media (min-width: 768px) and (max-width: 1023.98px) {
padding: 40px;
}
}
Le
padding par défaut du navigateur pour notre bloc est « 0 ». Par conséquent, au lieu d’ajouter une requête média de bureau et d’utiliser unset ou « 0 » pour la valeur de padding (ce qui serait nécessaire avec le mode « mobile-first »), nous pouvons envelopper le remplissage mobile dans une requête média fermée (puisqu’il s’agit désormais d’une exception) afin qu’il ne soit pas détecté aux points d’arrêt plus larges. Au point d’arrêt de l’ordinateur de bureau, nous n’aurons pas besoin de définir un style de padding, car nous voulons la valeur par défaut du navigateur.Regroupement ou séparation des CSS
À l’époque, il était très important de réduire le nombre de requêtes au minimum en raison de la limite de requêtes simultanées imposée par le navigateur (généralement autour de six). Par conséquent, l’utilisation de sprites d’images et le regroupement des CSS étaient la norme, tous les CSS étant téléchargés en une seule fois, sous la forme d’une seule feuille de style avec la plus haute priorité.
Avec l’arrivée de HTTP/2 et HTTP/3, le nombre de requêtes n’est plus aussi important qu’auparavant. Cela nous permet de séparer le CSS en plusieurs fichiers par media query. L’avantage évident est que le navigateur peut désormais demander le CSS dont il a besoin avec une priorité plus élevée que le CSS dont il n’a pas besoin. Cela est plus performant et peut réduire le temps global de blocage du rendu de la page.
Quelle version de HTTP utilisez-vous ?
Pour déterminer la version de HTTP que vous utilisez, rendez-vous sur votre site Web et ouvrez les outils de développement de votre navigateur. Ensuite, sélectionnez l’onglet Réseau et assurez-vous que la colonne Protocole est visible. Si « h2 » figure dans la colonne Protocole, cela signifie que HTTP/2 est utilisé.
Remarque : pour afficher le protocole dans les outils de développement de votre navigateur, allez dans l’onglet Réseau, rechargez votre page, cliquez avec le bouton droit de la souris sur n’importe quel en-tête de colonne (par exemple, Nom) et vérifiez la colonne Protocole.
Note : pour une comparaison résumée, voir « HTTP/2 vs. HTTP/1 » d’ImageKit.
Par ailleurs, si votre site utilise encore HTTP/1… POURQUOI ? !! Qu’attendez-vous pour le faire ? Il existe un excellent support utilisateur pour HTTP/2.
Diviser le CSS
Séparer le CSS en fichiers individuels est une tâche intéressante. Le fait de lier les différents fichiers CSS à l’aide de l’attribut
media approprié permet au navigateur d’identifier les fichiers qui sont nécessaires immédiatement (parce qu’ils bloquent le rendu) et ceux qui peuvent être différés. Sur cette base, il attribue à chaque fichier une priorité appropriée.Dans l’exemple suivant d’un site Web visité sur un mobile, on peut voir que les CSS mobile et par défaut sont chargés avec la priorité « Highest », car ils sont actuellement nécessaires au rendu de la page. Les autres fichiers CSS (impression, tablette et bureau) sont toujours téléchargés au cas où ils seraient nécessaires ultérieurement, mais avec la priorité « la plus faible ».
Avec un CSS groupé, le navigateur devra télécharger le fichier CSS et l’analyser avant que le rendu puisse commencer.
En revanche, comme nous l’avons indiqué, si le CSS est séparé en plusieurs fichiers liés et marqués par l’attribut media correspondant, le navigateur peut donner la priorité aux fichiers dont il a besoin. L’utilisation de plages de requêtes média fermées permet au navigateur d’effectuer cette opération pour toutes les largeurs, contrairement aux requêtes classiques de type « mobile-first min-width« , où le navigateur de bureau devrait télécharger toutes les CSS avec la plus haute priorité. 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 à l’internet sont encore faibles.
Les requêtes média et le nombre de fichiers CSS distincts varieront d’un projet à l’autre en fonction des exigences du projet, mais pourraient ressembler à l’exemple ci-dessous.
CSS groupé
<link href="site.css" rel="stylesheet">Ce fichier unique contient toutes les feuilles de style CSS, y compris toutes les requêtes média, et il sera téléchargé avec la plus haute priorité.
CSS séparé en plusieurs fichiers
<link href="default.css" rel="stylesheet"><link
href="mobile.css" media="screen and (max-width: 767.98px)"
rel="stylesheet"><link href="tablet.css" media="screen and
(min-width: 768px) and (max-width: 1083.98px)"
rel="stylesheet"><link href="desktop.css" media="screen and
(min-width: 1084px)" rel="stylesheet"><link href="print.css"
media="print" rel="stylesheet">Le fait de séparer les feuilles de style CSS et de spécifier une valeur d’attribut de média sur chaque balise de lien permet au navigateur de donner la priorité à ce dont il a actuellement besoin. Sur les cinq fichiers énumérés ci-dessus, deux seront téléchargés avec la plus haute priorité : le fichier par défaut et le fichier qui correspond à la requête média actuelle. Les autres seront téléchargés avec la priorité la plus basse.
En fonction de la stratégie de déploiement du projet, la modification d’un fichier (
mobile.css, par exemple) n’exigera de l’équipe d’assurance qualité qu’un test de régression sur les périphériques de cette plage de requêtes média spécifique. Comparez cela à la perspective de déployer le seul fichier groupé site.css, une approche qui déclencherait normalement un test de régression complet.Aller de l'avant
L’adoption du CSS » mobile-first » a été une étape très importante dans le développement web ; elle a aidé les développeurs frontaux à se concentrer sur les applications web mobiles, plutôt que de développer des sites sur ordinateur et d’essayer ensuite de les adapter à d’autres appareils.
Je ne pense pas que quiconque souhaite revenir à ce modèle de développement, mais il est important de ne pas perdre de vue le problème qu’il a mis en évidence : les choses peuvent facilement devenir alambiquées et moins efficaces si nous donnons la priorité à un appareil particulier – n’importe quel appareil – sur les autres. Pour cette raison, se concentrer sur le CSS en tant que tel, en gardant toujours à l’esprit ce qui est le paramètre par défaut et ce qui est une 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 le travail de test et de maintenance est également un peu plus simplifié et productif.
D’une manière générale, 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 dans des cercles de surcharges. Mais quelle que soit la méthode choisie, elle doit être adaptée au projet. L’approche « mobile-first » peut s’avérer être le meilleur choix pour ce qui est impliqué, mais vous devez d’abord bien comprendre les compromis que vous faites.
A propos de l’auteur
Patrick Clancey construit des sites Web depuis l’époque de Netscape Navigator et se passionne pour tout ce qui touche à l’accessibilité et à l’expérience utilisateur. Il a travaillé sur de nombreux projets au fil des ans, notamment pour Sony, Unilever, Ford, Shell et GSK, pour n’en citer que quelques-uns. Sa passion pour l’accessibilité est née alors qu’il travaillait dans le secteur de la santé sur une application pour le NHS. Actuellement, il est senior UI dev et travaille chez WTT à Londres.
Bonjour ,
Merci d’avoir partager responsively.app sur votre page suivante: multiverseconcept.com/css-pour-les-mobiles-est-il-temps-de-repenser-le-systeme/
Lors de recherches sur Google, je suis tombée sur un autre outil que j’ai trouvé super cool et tolament gratuit.
https://www.websiteplanet.com/fr/webtools/responsive-checker/
Il vous permet de vérifier si votre page est réactive et d’avoir un aperçu du design sur différents appareils (y compris smartphones et tablettes, ainsi que sur des résolutions personnalisées) – ce que je trouve génial.
En plus de cela, vous avez la possibilité de naviguer le site à l’intérieur de chaque écran (vous permettant ainsi de vraiment tester la réactivité du site).
Je voulais le partager avec vous car je pense que cet outil serait très pertinent pour votre page et je suis convaincue que vos lecteurs l’apprécieront également.
Bien à vous,
Dana.
Merci Dana,
Je ne manquerai pas de tester l’outil « Responsive Checker » pour vérifier la réactivité des pages.
Mais j’utilise Elementor qui possède déjà un testeur responsive pour visualiser sur Mobile, Tablette et Desktop.
Malgré tout, c’est toujours intéressant de tester sur 2 logiciels différents sur des pages un peu complexe.
Merci pour le lien