Responsive design: retour d’experience

Le développement du thème actuel m’a permis de travailler sur deux techniques: le couple HTML5/CSS3 d’une part, et le « Responsive Design » d’autre part. Comme je l’ai fait précédemment pour HTML5/CSS3, je vous présente, dans cet article, mes commentaires sur le design « responsive ».

Grille fluide ou Grille fixe?

Le responsive design est basé sur trois composants

  • une grille fluide,
  • les média-queries (voir cet article pour en savoir plus),
  • un contenu fluide (images, …).

Les grilles fluides, c’est compliqué!

Hors gérer une grille fluide reste plus difficile que de gérer une grille fixe. Les frameworks proposant une grille fluide ne résolvent pas tout. Dans certains cas (comme un mélange de colonnes fixes et fluides), il faut faire appel à des techniques plus ou moins complexes, et plus ou moins robustes en fonction du navigateur (imbrication de blocs <div>, marges négatives, …).

Je me suis donc posé la question: les notions de « design responsive », et de fluidité sont-elles réellement indissociables? Car elles sont finalement très différentes:

  • Dans le premier cas, nous modifions les propriétés des styles, pour que la structure soit adaptée à la taille de l’affichage,
  • Dans l’autre, les propriétés des styles ne changent pas, mais leurs valeurs permettent d’avoir une structure proportionnelle à l’affichage.

Nous pourrions très bien mettre au point plusieurs grilles fixes, que nous n’aurions plus qu’à sélectionner avec les media-queries.

Pour moi, l’utilisation d’une grille fluide n’est donc pas obligatoire. Cependant …

Alors grille fixe?

En supposant que nous utilisions une grille fixe (des grilles, en fait), il nous faudrait d’abord définir les tailles cibles. Hors, même si nous n’avions que les résolutions « standards » à gérer, il nous faudrait près de 10 grilles différentes (1280px, 1024px, 960px, 800px, 768px, 640px, 600px, 480px, 320px, 200px). Et là, je ne parle que de résolutions d’écran, pas des dimensions de la fenêtre du navigateur.

Une grille fixe cumule plusieurs inconvénients:

  • Elle oblige à traiter séparément un très grand nombres de cas, avec pour conséquence, un nombre important de styles, une lourdeur du fichier CSS, une mise au point, et des  maintenances plus longues
  • Même en prévoyant beaucoup de cas, le design sera très souvent mal adapté: soit trop petit, laissant apparaître de grands espaces vides, soit trop grand, l’utilisateur étant obligé, dans ce second cas, à scroller horizontalement.

Non, grille fluide !

Les grilles fixes permettent un positionnement extrêmement précis des différents éléments de la structure, mais elles deviennent donc ingérables, lorsqu’il s’agit de prendre en compte de nombreuses résolutions différentes.

Nous ne pouvons donc pas échapper à cette grille fluide.

Structure responsive

La conception d’un design « responsive » suit globalement la démarche suivante:

  1. Construction d’une grille fluide,
  2. Recherche des points de rupture ou de transitions (break points), qui sont les dimensions au-delà desquelles le design ne s’affiche plus correctement,
  3. Ecriture des styles qui rendent la structure de nouveau lisible,
  4. Activation de ces styles en fonction de conditions (media-queries),

Cette démarche, telle qu’elle est décrite, donne encore plus de sens au choix d’une grille fluide. La grille fluide se charge de gérer la structure entre des points de rupture, qui eux, sont gérés par les média-queries.

Ne pas multiplier les conditions

Les média-queries sont simples à comprendre, et à utiliser. Mais il faut veiller à ne pas en abuser. Lorsque le nombre de conditions augmente, la mise au point devient beaucoup plus complexe:

  • le repérage des styles utilisés est plus long (merci à Firebug cependant qui facilite quand même beaucoup les choses),
  • les erreurs sont plus difficiles à trouver,
  • les interactions entre les styles se multiplient, ce qui ne facilite pas la tâche, des navigateurs,
  • plus généralement, la feuille de styles est beaucoup moins lisible.

Multiplier les conditions, c’est également déclarer plusieurs fois les mêmes styles, et donc alourdir très sensiblement le poids de la feuille de styles.

D’ailleurs beaucoup de frameworks CSS qui proposent des grilles responsives, ne gèrent qu’un ou deux points de rupture seulement. Foundation, par exemple n’en gère qu’un à 768px.

Quelques conseils sur l’utilisation des média-queries

En plus du conseil précédent, ma première expérience sur le sujet, m’a conduit aux conclusions suivantes:

  1. Eviter d’avoir des chevauchements: Faîtes en sorte qu’une seule des conditions de s’active à un instant t. Cela facilite la mise au point, en évitant beaucoup de confusions,
  2. Attention à l’ordre d’apparition des conditions: Comme les conditions sont souvent de la forme min-width, ou max-width, il faut veiller à ce qu’elles soient dans le bon ordre,
  3. Prendre des grandes marges de sécurité: les grilles fixes nous ont donné l’habitude de construire des pages au pixel près. Avec les grilles fluides, les choses sont moins précises, et il vaut mieux définir les transitions qui soient assez éloignées des point de rupture,
  4. Prévoir des styles qui s’appliqueront par défaut, pour les navigateurs qui ne savent pas gérer les média-queries.

L’exemple ci-dessous est à éviter: les deux conditions s’activent, pour des résolutions comprises entre 320 et 480px.

1
2
3
4
5
6
@media only screen and (max-width: 480px) {
	... ...
}
@media only screen and (min-width: 320px and min-width: 640px) {
	... ...
}

Exemple de styles définis hors des média-queries, pour les « anciens » navigateurs :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
.class1 {}
.class2 {}
...
. class-n {}
 
@media-queries ... {
	.class1 {}
	.class2 {}
	...
	. class-n {}
}
 
@media-queries ... {
	.class1 {}
	.class2 {}
	...
	. class-n {}
}

Méthodologie

Le premier conseil porte sur la feuille de styles elle-même: pour faciliter le travail sur les média-queries (et alléger leur contenu), il faut séparer, dès le début, les styles de grilles, des styles de mise en forme.
Au lieu d’avoir:

1
2
3
4
5
6
p.warning {
	width: 80%;
	margin: 0 auto;
	background: yellow;
	font-size: 2em;
}

Préférer cela:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/* -----
   -- Partie de la feuille de styles dédiée aux styles de grille
   ------------------------------------------------------------------------------ */
	p.warning {
	  width: 80%;
	  margin: 0 auto;
	}
 
/* -----
-- Partie de la feuille de styles dédiée aux styles de mise en forme
------------------------------------------------------------------------------ */
	p.warning {
	  background: yellow;
	  font-size: 2em;
	}

Ce conseil n’est pas nouveau, mais il devient particulièrement utile avec les média-queries.

Approche globale

Pour les média-queries elles-mêmes, plusieurs méthodes sont possibles:

Approche 1

  • Définir d’un certain nombre de résolutions limites (768, 640, 480px par exemple),
  • Ecrire des styles pour adapter la page entière à cette résolution.

Approche 2

  • Répérer les points de transitions des principaux éléments de la page,
  • Ecrire les média-queries qui correspondent,

La première approche est typiquement utilisée par les frameworks CSS. Son principal avantage réside dans sa simplicité. Nous n’avons a gérer que deux ou trois média-queries. L’inconvénient majeur est que les changements de styles ne correspondent va forcement au point de rupture des éléments de la page.

La seconde méthode est la plus précise, mais elle nécessite une certaine rigueur, car nous pouvons nous retrouver très vite avec des dizaines de conditions.

Personnellement, j’ai commencé par la seconde. Mais en voyant la simplicité des feuilles de styles de certains sites ou framework, qui utilisent l’approche 1, je me pose des questions.

Pensez mobile d’abord?

Le « responsive design » est relativement nouveau, et les méthodes de travail ne sont pas « normalisées » (pour ne pas dire patternisées). Les articles/livres disponibles nous proposent donc différentes principes, comme

  • Pensez mobile d’abord,
  • Utilisez la condition min-width uniquement,
  • et la réciproque: utilisez la condition max-width uniquement

Personnellement, je n’ai pas le recul suffisant pour dire qu’une méthode est meilleure qu’une autre. L’important, me semble être, de bien définir, dès le départ, l’ordre des blocs HTML. C’est d’ailleurs, à mon avis, le sens de la phrase « Pensez mobile d’abord » : l’affichage sur un smartphone est assez linéaire, tous les éléments étant empilés verticalement. L’ordre d’affichage sur smartphone est donc l’ordre des blocs HTML dans votre page. Pour des résolutions plus importantes, nous pouvons ensuite changer l’ordre d’affichage de ces blocs, avec les styles CSS.

Gérer le contenu

Jusqu’à présent, j’ai principalement parlé des média-queries, pour transformer la grille. Mais ces transformations ne servent à rien si le contenu ne suit pas. Il faut donc également gérer le contenu: les images, les tables, les vidéos, …

Pour les images, la solution existe. Le code suivant rend l’image « fluide »:

1
2
3
4
5
img {
	max-width: 100%;
	width: auto;
	height: auto;
}

Il existe le même type de « pattern » pour les vidéos, et plus généralement pour les objets « embarqués » (Google docs par exemple).

Pour les tables, j’avoue ne pas avoir de réelle solution: j’ai bien essayé de réduire les marges, ou la taille de la police de caractères, mais l’impact sur la taille de la table est limité.

Les techniques CSS sont-elles suffisantes?

Le principe du responsive design est de s’appuyer sur les fonctionnalités du couple HTML/CSS, pour fournir plusieurs formes d’un même site. Mais est-ce suffisant?

Plusieurs arguments montrent que non:

  • Nous sommes souvent dépendants d’un CMS, ou d’un moteur de blog. Ce moteur fournit un code HTML qui n’est pas toujours adapté au responsive design. Il faudra donc passer par une transformation de ce moteur (par des plugins, ou des fonctions du thème),
  • Gérer l’affichage pour de petits écrans, est déjà une très bonne chose. Mais l’ergonomie d’une page se juge autant sur sa vitesse de chargement, que sur la qualité de son affichage. Hors, d’une manière générale, les équipements dont l’écran est petit, sont également ceux qui ne disposent pas d’une grande bande passante. Donc, si nous affichons le même contenu, mais en plus petit (une image par exemple), cela ne change rien, ni au poids de la page, ni à la bande passante nécessaire pour la charger. Dans le même esprit, nous faisons souvent appel à l’attribut display:none sur les éléments que nous ne souhaitons pas faire apparaître sur les smartphones. Ces éléments sont invisibles, mais ils sont toujours là,
  • Malgré tout l’arsenal dont nous disposons pour adapter la taille de tous les éléments d’une page, certains éléments sont difficilement présentables sur petits écrans. Les tables cités plus haut sont un bon exemple,
  • Pour finir, changer le style d’une page peut suffire à la rendre lisible. Mais pour un site Web, l’ergonomie compte également beaucoup. Pour la navigation, par exemple, un fil d’ariane est parfaitement adapté à l’affichage sur un grand écran, mais absolument pas sur un smartphone. Le contenu doit également être adapté: si je prends l’exemple des galeries de ce blog. Sur PC, j’utilise des vignettes, et Shadowbox pour l’affichage des photos en surimpression. Est-ce la bonne approche sur smartphones?

Nous pouvons donc dire que l’approche « Responsive » ne peut pas être uniquement adressée avec les feuilles de styles, et qu’il faut également une adaptation du moteur (CMS ou moteur de blog), ce qui change beaucoup de chose en terme de travail nécessaire.

Conclusion

Les media-queries sont un formidable outil. Elles permettent de transformer la structure d’une page, avec un minimum d’effort. Plus besoin de multiplier les feuilles de styles, ou les versions de sites. L’utilisation d’une grille fluide, et des media-queries peuvent largement suffire à gérer l’affichage d’un site simple, ou d’un blog.

Mais pour des designs plus complexes, ou des sites dont le contenu est hétérogène, ces deux techniques seules ne suffisent pas. Elles doivent être considérées comme des composants d’une boîte à outils, dans laquelle figurent également une personnalisation du moteur de blog, ou du CMS, ainsi qu’un filtrage / une adaptation du contenu.

Références

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *