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.

5 commentaires sur cet article

  1. Raphaël Goetter, le dimanche 23 décembre 2012 à 12:06

    Très bel article synthétique, merci.
    Par contre, selon moi, la principale question qui se pose – au-delà de la technique – est de savoir s’il est vraiment pertinent d’imposer un format « retina » (donc lourd) aux utilisateurs sur écrans haute résolution qui n’ont rien demandé, et surtout qui sont en situation de connectivité faible.
    En clair, dans le métro je préfère de loin avoir un affichage rapide que précis au pixel près pour les images.

  2. Kaelig, le dimanche 23 décembre 2012 à 12:14

    Très bon article. Rappelons que certaines choses ne sont pas simples quand on a à faire aux écrans haute densité. Notamment ceux qui ont une densité de 1.3 ou 1.5, où l’on note des artefacts visuels au moindre demi-pixel mal ajusté.

    Et pour les fainéants comme moi qui aiment que la machine travaille à leur place, j’ai partagé un @mixin Sass appelé hidpi() : http://git.io/hidpi

    Ce mixin permet de servir aux écrans haute densité des images (ou toute propriété alternative). Plus besoin de saisir les @media queries qui vont bien, le mixin s’en charge pour vous.

  3. Nico, le dimanche 23 décembre 2012 à 14:14

    Je rejoins assez Raphaël sur l’emploi d’images lourdingues : avec une connectivité pourrie, je préfère privilégier la rapidité. Ceci dit, je constate que l’optimisation des images y est pour beaucoup : j’ai remarqué qu’une bonne balance qualité/poids sur les jpeg donne des résultats corrects sur certains écrans retina, ce qui évite la case « production d’images supplémentaires », particulièrement rébarbative.

    Après, vive les propriétés CSS pour certains effets/éléments, ça vire de facto ces problèmes !

  4. Ombre, le mercredi 26 décembre 2012 à 21:13

    Que pensez-vous de cette technique ? Apparemment certains y pensent sérieusement sur des sites en production… http://blog.netvlies.nl/design-interactie/retina-revolution/

    Plus de problèmes de poids d’images. ;-)

  5. Michaël, le vendredi 22 février 2013 à 04:03

    @Ombre :
    Cette technique réduit certes le poids des images mais cause d’autres problèmes, dont le plus important est l’explosion de la quantité de mémoire RAM consommée. Car bien qu’effectivement plus légères à télécharger, ces images gigantesques vont consommer beaucoup plus de mémoire que des fichiers « classiques », la consommation de RAM étant plus ou moins directement liée aux dimensions de l’image.

    Étant donné que la RAM disponible est souvent limitée sur les appareils mobiles et/ou étant donné que l’on peste déjà suffisamment contre l’apparente mauvaise gestion de la mémoire par les navigateurs (ce qui est souvent injustifié, la source du problème étant principalement les sites utilisant de plus en plus de ressources lourdes), augmenter la consommation de RAM afin d’améliorer la vitesse de chargement m’apparaît comme échanger un gros problème par un autre…

    Autrement dit, c’est loin d’être une solution miracle, malheureusement…