La tête dans le Flux !

Deux (ah non, cinq) tests de navigation mobile

Très rapidement, voici pour partage et discussion, quelques expériences de menus de navigation adaptés pour le Web mobile (redimensionnez la fenêtre si vous consultez à partir d’un ordinateur de bureau)

1. Premier menu (navigation défilant de la droite vers la gauche) : http://bit.ly/goetter-menu3
2. Deuxième menu (navigation défilant de la gauche vers la droite) : http://bit.ly/goetter-menu3b
3. Troisième menu (navigation défilant du haut vers le bas) :
   http://bit.ly/goetter-menu3c
4. Quatrième menu (navigation sur une ligne apparaissant par en haut) http://bit.ly/goetter-menu4
5. Cinquième menu (le corps de page descend et dévoile le menuà :
   http://bit.ly/goetter-menu5

Objectif et contraintes

Mes contraintes étaient celles ci : n’avoir aucune requête, aucun fichier à télécharger, ni aucun script à faire mouliner (bref : pas d’image, ni JavaScript, ni icon-font)

Compatibilités :

• OK sur iPhone3 Safari, iPhone4 Safari, Android 3, Android 4, Opera mobile
• Pas OK sur Firefox mobile, Opera mini et anciens navigateurs de manière générale

Attention : Ces expériences ont été réalisée rapidement et je n’ai pas testé sur tous les environnements existants. En clair, je ne suis pas responsable si tout explose :) (merci en passant à @walterstephanie pour les tests)

À propos de rétina et d’images floues

“Rétina”, “retina display” et “retina HD”, sont de bien jolis mots marketing que personne ne saurait définir exactement.

De manière très succincte, parce que je n’ai aucune envie de m’attarder sur ce point, disons tout simplement que “retina” a commencé par désigner la génération iPhone 4 aux résolutions de 960×640px au lieu de 480×320px dans les modèles précédents. Le terme désigne aujourd’hui tout périphérique nomade (tablette ou smartphone) doté d’un écran haute résolution.

Toujours est-il que pour le quotidien d’un développeur web mobile, les différences de rendu selon les résolutions sont loin d’être une partie de plaisir. D’autant plus que les terminaux Apple (iPhone, iPod et iPad) ont la fâcheuse habitude de mentir sur leurs résolutions en mentant sur leur device-width.

Prenons un exemple courant: l’iPhone4 ou 4S. Sa largeur physique est de 640px, mais il déclare un device-width de 320px (en largeur et en hauteur).
En lui appliquant - avec raison - une balise meta viewport de valeur “width=device-width”, il se prend pour un écran de 320px de large… tout en conservant sa précision de 640px.

Les contenus affichés, surtout les images, sont alors interpolées et interprétées comme “doublées”. Un peu comme un large écran de bureau auquel vous imposeriez une résolution de 800x600px : l’interpolation est parfois hasardeuse et manque de précision. Disons-le franchement, c’est parfois un peu flou.

Pour mieux comprendre, voyons le phénomène à travers plusieurs exemples concrets. Des vraies images HTML (img) pour commencer, puis des images d’arrière-plan.

Cas des images HTML

Cas des arrière-plans CSS

Alors, on peut y faire quelque chose ?

Pour contrer ce souci de finesse dans le rendu, les solutions ne sont pas si évidentes car il ne suffit pas de détecter les résolutions HD ou les pixel-ratios.

Voici les hypothèses que j’entrevois :

1. Ne rien faire.
   En toute honnêteté, ce n’est pas une catastrophe d’afficher des images classiques sur un écran haute définition, mais c’est un peu dommage car l’avenir appartient aux mobiles “rétina”.
2. Servir des images “un peu plus grandes” que la largeur finale affichée.
   Par exemple, pour un picto de largeur 32px, afficher une image de 64px. Idem pour les images d’arrière-plan, en pensant à préciser un background-size de 100% auto. C’est une bonne solution intermédiaire à condition de ne pas en abuser car le poids des images aura une incidence non négligeable sur le temps de chargement et d’affichage sur anciennes générations non rétina.
3. Servir des images différentes selon la définition d’écran des mobiles.
   Cela peut se faire du côté client ou serveur et c’est forcément la meilleure solution… et la plus contraignante. Tournez-vous par exemple du côté du script “Retina Images”, de RetinaJS ou celui de adaptive-images.com.

Et vous, vous avez d’autres pistes ? Des solutions ?

table-cell et responsive design

Il y a quelques jours, Vincent de Oliveira (futur orateur de notre presque célèbre Kiwi Partÿ) s’est amusé avec display table en vue de créer un gabarit “responsive”, c’est à dire qui s’adapte aux différentes résolutions d’écran.

Sa conclusion fut que l’exercice n’est pas aussi simple que prévu, et qu’en production il faudrait cumuler les imbrications d’éléments.

Étant un grand fan des tableaux, j’ai bien évidemment été frustré par ce verdict. Il n’en fallait pas plus pour me titiller et j’ai pris ça pour un défi à relever.

Le modèle d’affichage de type “display: table” a des particularités extraordinaires. L’une d’entre-elles est d’automatiquement générer des conteneurs anonymes. Par exemple, si un élément de type display: table-cell n’a pas de parent physique sous forme table-row ou table, il l’invente.

Le mécanisme des ancêtres anonymes est pour le moins complexe et alambiqué, mais va bien nous arranger pour relever le défi lancé.

En fait, je ne vais pas faire durer le suspense : il suffit de changer le rendu d’un seul élément en table-cell sans intervenir sur ses frères.

Vous verrez le résultat sur cette page de test.

Explications :

• En mode grand écran, chaque élément est affiché en mode de rendu “table-cell”. Il s’affichent donc 3 colonnes.
• En mode “tablette”, un seul des éléments passe en table-cell. Il se crée alors un contexte anonyme autour de lui (il s’invente un parent de type “table-row” et un grand-père “inline-table” ?) qui conduit à un affichage sous forme de 2 colonnes.
• En mode “mobile”, les éléments sont affichés sous forme de blocs, les uns sous les autres pour ne former qu’une seule colonne

Je vous disais bien que les tableaux de mise en page, c’est bien ! :)

media queries et performances web mobile

Ce billet fait suite à mes expérimentations continues concernant la performance web pour les mobiles. J’en étais arrivé à un billet nommé “comment cibler les mobiles de manière optimales (bis) ?”.

Voici la suite de mes élucubrations…

Un point sur l’existant

Il existe grosso-modo 6 méthodes d’application des CSS3 media queries :

1. un fichier CSS composé de styles généraux pour tous et de media queries pour mobiles.
   Problème : un navigateur mobile respecte les deux conditions à la fois (les styles globaux et ceux pour pour mobile), il va donc en toute logique charger les ressources… puis les masquer.
2. un élément <link> appelant une feuille CSS globale et une autre feuille CSS pour mobiles (via media queries).
   Problème : identique au précédent.
3. un fichier CSS unique composé de media queries exclusifs, par exemple @media (min-width : 641px) {…} / @media (max-width : 640px) {…}
   Problème : les anciens navigateurs dont Internet Explorer inférieur à IE9 ne reconnaissent pas media queries et n’auront qu’une page HTML brute de styles.
4. un élément <link> appelant des feuille CSS exclusives via media queries (une pour grands écrans et une autre pour mobiles).
   Problème : identique au précédent.
5. appliquer une rustine sous forme de commentaires conditionnels pour cibler les anciennes versions d’Internet Explorer.
   Problème : cette méthode nécessite une requête de fichier CSS supplémentaire, généralement non parallélisée.
6. se baser sur des alternatives JavaScript telles que Respond qui émule les media queries sur les anciennes versions d’Internet Explorer.
   Problème : cette méthode nécessite une requête de fichier JavaScript ainsi que son traitement par le navigateur.

Une méthode pour les réunir toutes ?

Plus j’y réfléchis, plus je suis persuadé qu’une solution intermédiaire est de distinguer 3 parties dans le fichier CSS :

1. les styles de base, qui doivent être affichés sur tous les supports (pas de media query)
2. les ressources lourdes, qui doivent être chargées uniquement sur écrans larges (via media queries)
3. les styles et adaptations spécifiques pour petits écrans (via media queries)

Grâce aux classes conditionnelles, nous pourrons également en faire profiter les anciennes versions d’Internet Explorer sans douleur.

Voici un exemple concret :

/* styles pour tous */
body {width: 960px; background: #fff;}

/* ressources CSS lourdes uniquement */
@media (min-width : 641px) {body {background: url(concombre_big.jpg);}}

/* ressources lourdes aussi pour IE6-IE8 */
.oldie body {background: url(concombre_big.jpg);}

/* styles pour petits écrans */
@media (max-width : 640px) {body {width: auto; background: url(concombre_small.jpg);}}

Au final, il me semble que tous les écueils de performance sont évités, au prix d’une répartition plus réfléchie des ressources.

Cette méthode a actuellement ma préférence car ne nécessite pas de fichier CSS (donc de requête) supplémentaire, ni d’alternative et de traitement via JavaScript.