CSS, approche modulaire, Responsive Design sans Media Queries

Responsive design, pourquoi ?

Le responsive design est né en 2010

Un webdesigner, Ethan Marcotte, pointe l'écart entre la conception, pensée sur les bases du support imprimé, et son application sur les supports web.

Écart amené à se creuser en raison de l'émergence toujours grandissante de nouveaux supports.

Citant John Allsopp, qui dès 2000 s'interrogea sur cette distorsion en analysant la conception web à travers le prisme du Tao, il pose les bases du Responsive Design.

Responsive design, comment ?

Ethan Marcotte propose comme solution technique l'utilisation de Media Queries.

L'idée est d'utiliser une série de Media Queries, basée sur des résolutions "types" d'appareil, et de retravailler le style du contenu sur chaque plage de taille.

12 ans plus tard, cette approche fait-t-elle toujours sens ?

Concernant la multiplicité de type de support media, les statistiques corroborent ce qu'il prévoyait il y a 12 ans.

( Source : https://gs.statcounter.com/screen-resolution-stats )

Amplitude de largeur d'écran "typique" à couvrir, basée sur les statistiques de résolutions d'écrans mondiales, représentant plus de 2% du marché

% de résolutions " atypiques " (non incluses dans les 20 les plus représentées)

2010 : ≃ 9%
2015 : ≃ 28%
2022 : ≃ 43%

L'amplitude des largeurs d'écran connues les plus représentées, et le % de résolutions atypiques n'ont pas significativement évoluées en 2024. On note que la représentation de la résolution 1366 x 768 continue de baisser, tandis que la résolution 360 x 800 est en augmentation, sans impact majeur.

Si l'on ajoute à cela l'extension du marché du numérique, et la multiplication de l'offre, rendant la concurrence féroce, maximiser l'expérience du plus grand nombre d'utilisateurs est devenu un enjeu primordial pour les acteurs du marché. Le responsive design est donc plus que jamais d'actualité.

Responsive design, l'évolution

L'usage des Media Queries s'est affiné, assez rapidement les meilleurs pratiques ont fait glisser la media query du layout au contenu.

• Pour englober un nombre toujours croissant de résolutions différentes
• Pour se caler sur la conception modulaire par composants des développeurs

En effet, dès 2013, Brad Frost se penche sur la problématique d'une conception pensée par écran / page, tandis que la réalisation est pensé en composants factorisés et réutilisables.

Il crée alors le concept d'Atomic Design, et publie un livre à ce sujet en 2015, qui popularise cette approche.

Reste quelques problématiques non résolues :

1. le système de responsive par media queries alourdit considérablement le code et sa maintenance, de par la répétition engendrée.
2. l'augmentation du nombre de tailles "atypiques " à supporter provoque une multiplication de media queries pour une couverture effective sans perte de qualité de tous les utilisateurs, ce qui aggrave le point 1.
3. La réutilisation d'un même composant, dans des layouts différents, nécessite un comportement lié à la place de ce composant dans le layout, et non à la taille de la fenêtre.

Pour illustrer le point 3, un même composant dans 3 zones différentes :

Le même composant s'affiche de 3 manières différentes selon l'espace alloué sur l'écran large, mais de la même manière sur l'écran de petite taille.

En approche modulaire, le composant a son propre css, qui ne s'applique qu'à lui, chaque page également.

Il est tentant d'ajuster au cas par cas en surchargeant le css d'une occurrence donnée d'un composant par le css de la page qui l'héberge.

Une fausse bonne idée …

Se servir du css de la page pour modifier l'affichage du composant sur cette page donnée fonctionne, mais c'est une pratique risquée ( et court-termiste ).

En cas de modification de la structure/du style du composant, (mise à jour de la librairie, du design system, etc..) le risque que le css associé à la page ne fonctionne plus avec cette nouvelle version du composant n'est pas négligeable.

Il faudra alors faire une vérification avec possible correction de toutes les pages impliquées.
Ou renoncer à toutes mises à jour.

En terme de robustesse et de maintenabilité …

2021 : Naissance officielle des Container Queries

Les CSS Container Queries sont proposées en version bêta dans Chrome 93. La fonctionnalité est encore expérimentale et doit être activée manuellement via les flags de Chrome.

Depuis février 2023, cette fonctionnalité fonctionne sur les derniers appareils et versions de navigateurs. container - CSS: Cascading Style Sheets | MDN (mozilla.org)

Un polyfill est également disponible si besoin sur le gitlhub de Google Chrome Labs https://github.com/GoogleChromeLabs/container-query-polyfill

Responsive design, aujourd'hui : du full responsive sans media queries

Les container queries sont indispensables pour gérer un design adaptatif en fonction de la taille du container parent.

Dans le cas d'une conception full responsive, une autre solution consiste à combiner la puissance des flex et des grid à celle des fonctions mathématiques css, plus une pincée d'unités relatives, pour réaliser une intégration responsive basée sur le composant, prenant en compte la taille de son parent, tout en s'affranchissant des Media Queries.

Je n'expliquerai pas ici le fonctionnement des flexbox et grid, ainsi que les fonctions mathématiques en css, cela a déjà été très bien fait par d'autres.

A titre indicatif, une liste d'articles.

Guide des flexbox | Guide des grid | Auto-placement in CSS Grid Layout | Les fonctions mathématiques

Exemple : un dashboard full responsive sans media queries

Les propriétés css utilisées dans cet exemple

• flex, flex-basis : le layout 2 colonnes non équivalentes

Le header utilise la même méthode que ci-avant.

• grid, grid-template-columns : la répartition des blocs de la colonne de droite.

Listes blocs de tâches

Colonnes 50% / 50%

La liste de blocs de statistiques utilise la même méthode que ci-avant.

Liste de planning : layout de 2 colonnes fixes.

Résumé de l'ensemble des propriétés css qui pemettent de gérer le responsive de cet exemple (hors alignements)

Les gains

• Aucune dépendance, CSS simple.
• Code très léger et facile à maintenir.
• Le css des layouts est indépendant du css des composants
• Affichage optimal sur toute taille d'écran

Les prérequis

• Nécessite une conception responsive, et non adaptative fluide. Si la totalité de la conception a été pensé en adaptatif fluide avec dégradation gracieuse, il vous sera difficile de réaliser une interface full responsive.
  Mais pas impossible, car les containers queries permettent aujourd'hui de couvrir finement les cas de design adaptatifs.Le gain de temps de code et de maintenance sera cependant perdu.