Comme ce site est mon site perso, je m’en sers souvent pour expérimenter des solutions, pour voir si je sais les mettre en pratique (d’une part) et si je peux les préconiser dans le cadre de mon travail (d’autre part). Par exemple pour la version 6 les questions que je me suis posées sont :
- Peut-on faire du Mobile first qui tienne la route ?
- Est-ce difficile de faire du Responsive design, combien ça coûte ?
- Peut-on déjà mettre du HTML5 (notamment
figure
etfigcaption
qui permettent de remplacer avantageusement un<img src='bla.png' alt='tu ne vois ce alt que si tu le cherches' />
) ?
Le parc cible
En préambule je dois rappeler que ma cible est le parc grand public : tout le monde n’a pas un smartphone-qui-tue, tout le monde ne sait pas installer une version hyper récente de navigateur. Par exemple je tape ce texte sur un Windows XP professionnel (la machine que mon employeur met à ma disposition), donc je n’ai que IE8 et aucune possibilité de le mettre à jour [1].
Je n’ai aucune raison de préjuger que vous allez consulter mon site chez vous, avec une nightly de Firefox ou de Chrome [2]. Je dois donc considérer qu’au moins 50% de mes visiteurs utilisent Internet Explorer, et pas forcément la version la plus récente. Restez avec moi, ça a son importance dans les choix qui vont suivre.
HTML5 est-il mûr ?
Comme vous le savez, le consensus depuis les débuts du web, c’est qu’un navigateur qui ne comprend pas une balise l’ignore : il affiche ses contenus sans autre forme de procès (c’est ce qui nous permet de faire des dégradations élégantes quand un plugin n’est pas chargé, par exemple). Le hic avec Internet Explorer, c’est qu’il fait bien ce qu’on lui demande, sauf que faute de connaître la balise, il est incapable de la styler (donc pas de display:block;
et tutti quanti). Un type plus malin que moi a découvert qu’il suffit d’ajouter un élément factice dans le DOM avec ce nom de balise pour qu’IE la considère comme légitime et nous permette de la styler. Par exemple pour faire comprendre à IE qu’il existe bien un élément article
il suffit de lui dire qu’on a ajouté des éléments article
dans le DOM :
document.createElement('article')
Partant de là, peut-on se dire que tout va bien et qu’on peut donc utiliser toutes les chouettes balises de HTML5 dans un site en production, là, tout de suite ? La réponse est : ça dépend [3]
Pour un site perso comme celui-ci, il suffit d’aller chercher html5shiv.js et le tour est joué. Au pire le Javascript casse, le site est moche. C’est tout à fait supportable.
Pour un site pro, en revanche, la question se pose encore : sachant que le moindre octet compte sur un portail qui prend plusieurs millions de hits par jour, pour le moment ce n’est pas une si bonne idée.
Nous pourrons utiliser sans ennui les éléments sémantiques HTML5 quand IE8 aura disparu. Avant ça, prudence est mère de sûreté.
Media queries
On a dit qu’on faisait un site moderne, on doit donc s’attendre à ce que nos visiteurs accèdent à ce site avec une variété de terminaux différents : de l’écran 24 pouces au smartphone, de l’ordinateur portable à la tablette (je parle de Mobile first plus bas, promis, mais pour l’instant oublions-le le temps que je vous expose ma démarche).
Premier choix : quelle taille pour mon design ? Partant du principe que la plupart des gens qui consultent ce site sur un ordinateur ont un écran d’au moins 1024 pixels de large, j’ai choisi arbitrairement 922 pixels de large, soit 6 colonnes de 112 pixels, des gouttières confortables de 42 pixels, et 20 pixels de chaque côté pour faire un padding de confort. Ce qui nous fait un contenu central de 574px de large avec une police de base à 14px [4], encadré par des jolies marges dans lesquelles poser les figcaption
et les pavés de type « à propos de cet article ».
Ensuite, à quel endroit poser les points de rupture de votre design ? En fait il n’existe pas de règle, pas plus qu’on ne peut être sûr qu’un utilisateur navigue en ayant dimensionné son navigateur pour prendre la totalité de l’écran.
La méthode très simple que nous appliquerons est la suivante : redimensionnez votre fenêtre, et dès qu’une barre horizontale apparaît, considérez que c’est un point de rupture. Il faut alors faire une déclaration supplémentaire et commencer à « casser » le design : dans mon cas, en-deçà de 930px disponibles (je ne veux pas attendre le dernier moment pour des questions de confort visuel), réduire la marge gauche, ramener les figcaption
dans le flux de l’article puisqu’ils n’auront plus de place dans la marge gauche, commencer à indiquer aux images qu’elles ne doivent pas dépasser des bords en appliquant les bons conseils de tonton Raphaël :
img { max-width:100%; height:auto !important; box-sizing:border-box; }
De la même manière, en-dessous de 600px, je laisse quelques marges, j’enlève tous les float
, je ne fais plus appel aux web fonts (ça n’a que peu de sens sur un petit affichage), je fais des polices de titre moins grandes (400% sur un petit écran, ça peut tourner au cauchemar) et j’en profite pour surcontraster les polices.
Prenons deux secondes en passant pour parler de surcontraste : à la demande générale d’Olivier, qui souffrait de mon noir sur blanc très tranché dans la précédente version, j’ai opté pour un gris sombre (#333
) sur blanc, voire pour certains contenus « décoratifs » (les exergues [5], les dates, les liens visités) pour un gris plus clair (#666
). Profitons donc de nos media queries pour recontraster l’ensemble : allez zou, tout en noir sur blanc sur les petits affichages ! C’est une règle que je n’ai encore jamais vue dans les articles qui parlent de design réactif, et qui à mon avis est tout à fait pertinente [6].
Mobile first
Luke Wroblewski est un mec pas bête, et je suis sûr qu’il a beaucoup de bonnes raisons de prôner le Mobile first (bientôt je lirai son livre sur le sujet), notamment le fait qu’on part du contenu principal, celui dont on est sûr qu’il est demandé par le visiteur, puis on ajoute des choses autour (je résume grossièrement, hein). L’idée serait donc de faire un design pour mobile, puis d’ajouter des règles CSS d’enrichissement au fur et à mesure que la zone d’affichage du navigateur s’élargit, comme l’explique très bien Nicolas Torres dans son article sur Webdesign Friday.
Oui mais, on l’a vu plus haut, une grosse partie de nos visiteurs, jusque-là, n’ont pas encore accès aux media queries : Elles ne sont disponibles qu’à partir... d’IE9 (voir le tableau de support des media queries sur When can I use?).
Dois-je donc proposer à une partie encore non négligeable de mes visiteurs une version linéaire, pensée pour un petit écran, alors que par ailleurs leur navigateur est tout à fait en mesure d’afficher un design riche ? J’ai choisi de répondre non.
Note liminaire : le support de Windows XP arrive à son terme, la plupart de nos visiteurs vont donc devoir mettre à jour leur parc (et donc leur navigateur). On peut donc raisonnablement supposer que d’ici un an ou deux la réponse sera toute différente, mais pour le moment présent, non.
Donc, en résumé : j’ai une approche « content first » et autour je brode [7], j’ajoute la navigation, un footer riche (commentaires, liens vers twitter, informations légales). Pour le parc de mes visiteurs, là encore, le Mobile first n’est pas mûr.
Vue mobile
Pour autant, toute cette histoire de responsive design m’a permis sans trop d’effort d’avoir au final une CSS pour mobile : il me suffit d’aller jeter un œil dans mon Firebug, de copier/coller le rendu calculé en-deçà de 600px dans un fichier mobile.css
et d’y faire appel via un media='handheld'
. Ça fait toujours plaisir à Opera Mini et aux vieux navigateurs des téléphones à mi-chemin entre l’entrée de gamme et le smartphone.
Et puis tiens, pendant qu’on y est, regardons ce qui se fait autour de nous : Twitter, Flickr, etc. proposent tous un lien vers la « version mobile ». Qu’est-ce qu’ils changent ? Principalement ils linéarisent la page, servent des contenus avec très peu de styles, très peu d’images (et dans un format plus petit), et pas de scripts.
Je me suis donc nourri de cette idée-là pour proposer aux visiteurs, en opt-in, de choisir une version mobile. On pose un cookie, Spip génère des pages différentes selon le réglage. Profitons-en donc pour adapter le design, mais pas seulement :
- Fournissons uniquement la CSS
mobile.css
(qui ne fait pas de requête sur les web fonts, rappelez-vous) ; - Supprimons dans notre code tous les appels à Javascript [8] ;
- Réduisons les contenus : fournissons une image directement bridée en taille (par défaut elles font 574px, soit la largeur de notre colonne en vue « desktop », réduisons-les à 300px, ce qui devrait être suffisant même pour une petite résolution de smartphone à 320px), supprimons la moitié du contenu du footer (tous les liens vers Twitter sont accessoires sur mobile, par contre je conserve la « zone de rebond » des commentaires, des liens avant/après et évidemment les informations légales).
Vous allez me dire « oui mais moi j’ai beau avoir un smartphone, je viens de le brancher sur la borne wifi chez moi et je veux tout voir comme si j’avais un navigateur de bureau ». Qu’à cela ne tienne, il vous suffit de ne pas demander expressément la version mobile : les media queries sont là pour ça.
En résumé
La philosophie du mobile first est bonne, mais dans mon environnement cible le parc n’est pas encore mûr. De plus, cette approche me « bridait » un peu trop quand j’en étais à réfléchir à une mise en page pour la version desktop [9]. J’ai donc opté pour une approche content first (une voie moyenne, en somme), puis brodé autour, et fourni à l’utilisateur un moyen de voir le site dans une version très allégée.
On verra ce que ça donne à l’usage, encore une fois c’est une expérimentation. À mon avis un des premiers enseignements à tirer de tout ça, c’est au moins la notion de surcontraste sur petit écran ; c’est toujours ça de pris.