En 2013, passez au Retina !

Avertissement : « Retina » est une dénomination propriétaire d’Apple. Nous l’utiliserons comme abus de langage pour désigner les écrans HiDPI (haute densité de pixels par pouce).

Contexte

Le 4 juin 2010, c’est le jour où Steve Jobs introduit l’iPhone 4 avec un nouvel écran dit Retina avec une définition quadruplée qui nous fait entrer dans l’ère de la HiDPI (haute densité de pixels par pouce). Si les premiers instants d’utilisation sont absolument magiques, les intégrateurs et webdesigners ont immédiatement détecté un problème de taille ! En effet, la plupart des images apparaissent pixelisées.

En 2012, les écrans HiDPI se sont répandus comme une traînée de poudre avec d’un côté Apple qui fait du Retina à toutes les sauces (iPhone, iPad, iPod et MacBook Pro) et de l’autre côté Samsung qui réplique avec ses écrans Super Amoled Plus et Super Amoled HD.

Alors que chaque marque y va de son superlatif pour qualifier la qualité de ses écrans, on ne compte plus les différentes définitions possibles :

• 306 ppp pour le Galaxy S III ;
• 326 ppp pour l’iPhone 4 et supérieur ;
• 264 ppp pour l’iPad 3 et supérieur ;
• 227 ppp pour le MacBook Pro 13“ 2012 ;
• 220 ppp pour le MacBook Pro 15“ 2012 ;
• 320 ppp pour le Nexus 4 ;
• 300 ppp pour le Nexus 10 ;
• 254 ppp pour le Kindle Fire HD ;
• etc.

À propos de définition et de dpi, si vous pensez que « Le print c’est en 300 dpi, et pis le web c’est en 72 dpi. », je vous conseille de lire l’excellent article de Florent Verschelde. Pour la suite de cet article il faudra donc retenir qu’on doit penser en pixels et que la fameuse résolution de Photoshop à 72 dpi ne sert à rien !

Cependant, lorsque l’iPhone a une définition de 640 × 960 pixels… mais déclare n’en avoir que 320 × 480 (d’où le « Rétina » ou le « demi pixel »), on se sent un peu perdu…

Un peu de R&D pour industrialiser le passage à la HiDPI

Il existe de nombreuses méthodes aujourd’hui qui peuvent nous aider à supporter la HiDPI, par exemple les medias queries avec une condition sur la résolution ou encore la méthode de l’image-set qui est très bien expliquée dans cet article ; cependant elle n’est disponible qu’à partir de Safari 6 et Chrome 21.

Finalement la méthode d’industrialisation proposée ici est assez simple comparée à ces techniques « modernes » :

• Multiplier par deux la taille des images en sortie Photoshop. Attention cela suppose é́galement de
• multiplier par deux son espace de travail. Par exemple, si vous étiez habitué à travailler sur un fichier PSD de 1280 px de large, il vous faudra maintenant travailler sur un fichier de 3840 px. Une alternative à cette méthode coûteuse en mémoire consiste à travailler en full-vectoriel.
• Utiliser la propriété CSS « background-size ». La valeur de ce background size sera divisée par deux par rapport à la taille de votre image (en px).

Utiliser des CSS Sprite permet de mieux industrialiser.

Je ne reviendrai pas dans cet article sur l’intérêt d’utiliser des CSS Sprite. Cependant s’il vous manquait encore une raison pour utiliser cette technique, sachez que HiDPI et Sprite c’est un combo parfait ! Voyez plutôt…

Les images qui nécessitent un support optimal de la HiDPI sont surtout les images d’interface de votre site ou application (icônes, logo, background, etc.). À noter par ailleurs que les photographies, notamment en JPEG progressif, supportent assez bien le passage à la HiDPI et ne nécessitent pas obligatoirement un traitement particulier. Nous vous laisserons vous faire votre propre opinion sur un rapport qualité − coûts.

Conclusion : vous avez tout intérêt à réunir vos images d’interface au sein d’une feuille de Sprite qui aura une résolution × 2. Ainsi côté CSS vous n’aurez à déclarer qu’une seule fois votre fameux « background-size ». Attention, n’oubliez pas de diviser par deux tous vos « background-position » ! C’est là qu’il faut être fort en calcul mental !

Et les images placées dans le code HTML ?

Pour les images hors interface, si vous souhaitez avoir un support parfait de la HiDPI, la librairie RetinaJS pourra vous venir en aide. Cette petite librairie open source vérifie si le fichier de l’image d’une balise <img /> est disponible dans une définition supérieure en utilisant la convention de nommage « monimage@2x.jpg ». Plus d’explications ici.

À noter également qu’il existe un groupe de travail pour un support natif des différentes définitions d’images dans le code HTML. La solution pourrait venir de la balise <picture> qui, à l’image de la balise <video>, permet de définir différentes sources, ou de l’attribut srcset qui permettrait de charger le bon fichier en fonction de la définition. Vous trouverez plus d’information sur ce sujet sur l’article de Geoffrey Crofte.

Des pièges à éviter

Les demi-pixels, cela existe ?!

Le travers de la technique est que, lors de l’utilisation de CSS Sprite pour faire des « hover » ou « active », si les images ne sont pas calées sur une grille paire, vous pourriez obtenir des décalages d’un demi-pixel ! En effet, si l’image du hover n’est pas calée sur des pixels pairs, le positionnement parfait du hover en background-position est entre deux pixels (à X,5 px). À noter qu’on ne peut avoir de background-size ou background-position en X,5 px, c’est donc pour cette raison qu’il est indispensable de générer un fichier d’image en pixels pairs.

La limite iOS

Lors de nos travaux nous sommes tombés sur un bug méconnu. Les navigateurs de iOS (Safari, Chrome) ne sont pas capables de charger en mémoire une image de plus de 2 097 152 px (2 × 1024 × 1024 px). Le problème c’est qu’avec le support de la HiDPI, deux millions et quelques pixels c’est assez peu et on arrive rapidement à cette limite. Vous trouverez plus d’explications et de tests ici.

IE<9 toujours !

Comme d’habitude Internet Explorer pose problème. Avant Internet Explorer 9, Trident ne supporte pas la propriété « background-size ». Si vous souhaitez assurer le support de ce navigateur, vous en serez quitte pour une petite feuille alternative ainsi que la sortie de vos images en « résolution » normale. Il vous faudra adapter tous les « background-position » en cas d’utilisation de CSS Sprite. Avec un peu d’organisation dans votre feuille de style (OOCSS) cette surcharge n’est pas trop coûteuse.

Au-delà des images, des bonnes pratiques

Dans cet article nous avons essentiellement traité du support HiDPI pour les images. Il est évident qu’il ne faut pas oublier un certain nombre de bonnes pratiques qui vous aideront à supporter facilement le passage au Retina dans la production de vos projets web :

• utiliser les propriétés CSS pour vos dégradés vectoriels, boutons, etc. ;
• utiliser du dessin vectoriel (SVG/VML) pour vos graphiques, schémas, etc. De nombreuses librairies JavaScript permettent un très bon support sur les vieux navigateurs comme RaphaelJS, mais c’est un autre sujet…

Conclusion

Le support des écrans HiDPI requiert une surcharge de travail pour le webdesigner et pour l’intégrateur. Cependant le jeu en vaut largement la chandelle et cette surcharge est largement limitée avec un peu d’organisation.