Webdesign Friday (#wdfr) - La communauté des webdesigners francophones

Les vendredis Webdesign !Chaque semaine, un nouvel article par un professionnel du Web.

Adapter vos sites pour les écrans Retina

Adapter vos sites pour les écrans Retina

De la même manière que le Responsive Webdesign était une tendance débutée en 2011, les écrans à haute définition seront probablement le nouveau challenge de 2012. Apparus tout d’abord sur les mobiles puis employés sur le Nouvel iPad par Apple, les écrans de type Retina changent encore la donne. On parle même de leur apparition sur les ordinateurs de bureau.
Il est donc temps de se pencher sérieusement sur le sujet!

Note technique
Utilisés sur les iPhone 4 et Nouvel iPad, ces écrans ont la particularité d’avoir une résolution extrêmement élevée (320 dpi pour l’iPhone et 264 dpi pour l’iPad), rendant les pixels pratiquement indiscernables à l’œil nu.
Le terme “Retina” est une marque utilisée par Apple, Android utilise les termes HDPI (~240dpi) et XHDPI (~320dpi).

Un problème? Quel problème?

L’adaptation des sites pour les écrans à haute densité passe essentiellement par un travail sur les visuels (pictos, icônes, photos, etc.).
En les laissant tel quels, ils seront simplement “étirés”, laissant un rendu flou et des contours imprécis. Une expérience pas très flatteuse pour votre site.

Comparaison entre les iPhone 3G et 4

Comparaison entre les iPhone 3G et 4 avec leur écran à la même proportion de pixel

La densité de pixels peut donc donner du fil à retordre aux graphistes et webdesigners, mais pour le navigateur, la taille du viewport reste inchangée. Ces résolutions ne servent en fin de compte qu’à apporter plus de finesse.

Voyons maintenant quelques techniques pour gérer au mieux ce type d’écrans.

5 techniques à la rescousse

Du plus simple au plus complexe, voyons maintenant comment faire une beauté à vos sites!

Images à 200%

La technique la plus simple (mais un peu barbare) consiste simplement à doubler la taille de vos images:

<img src="images/my-image@2x.png" alt="Mon Image" width="400" height="300">
<!-- l'image source fait en réalité 800px par 600px -->

On intègre une image aux dimensions doubles de la taille qu’on souhaite afficher et on la diminue à 50%. On a donc suffisamment de pixels pour un affichage parfait sur écran à haute densité. Une seule image, une ligne HTML: that’s all folks!

Il y a cependant deux inconvénients:

Le premier est non négligeable puisqu’on impose le téléchargement d’images plus lourdes, même à ceux qui ont des écrans à densité classique et qui n’ont pas besoin d’une telle précision. En résulte des temps de chargement plus longs, particulièrement pour les petites connexions, en 3G par exemple.
Il est donc préférable d’utiliser cette méthode sur de simples logos ou éléments graphiques légers.

Le second défaut est dû aux moteurs de rendu. L’anti-aliasing (ou anti-crénelage) rend les contours de l’image un peu moins nets qu’ils ne le devraient. Un défaut acceptable pour des photos, mais beaucoup moins dans une optique “pixel-perfect” pour des pictogrammes ou icônes.

Les plus

  • Simple à mettre en place
  • Une seule image
  • Compatible avec tous les navigateurs

Les moins

  • Poids de l’image
  • Temps de chargement
  • Haute définition imposée pour tous
  • Problèmes d’anti-aliasing

Media Queries

Rendues populaires avec le Responsive Webdesign, on peut aussi se servir des Media Queries pour offrir des icônes à résolution doublées aux appareils à écrans à haute densité.

De la même manière que l’on peut détecter les largeurs d’un écran en CSS, l’exemple suivant vous permet de cibler sa densité de pixels. Notez que la propriété s’applique à tous les navigateurs pouvant l’interpréter.

@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
 only screen and (-o-min-device-pixel-ratio: 3/2),
 only screen and (min--moz-device-pixel-ratio: 1.5),
 only screen and (min-device-pixel-ratio: 1.5) {
  /*vos styles ici*/
}

Voyons un exemple simple de remplacement d’icônes pour les écrans à haute densité. Comme on l’a vu avant pour la redimension inline, nous allons voir ici comment le faire avec des background-image.

C’est la propriété background-size qui nous permet ici de réduire pour l’image à 50% de sa taille d’origine.

.icon{
  display: block;
  width: 30px;
  height: 30px;
}
@media only screen and (-webkit-max-device-pixel-ratio: 1.5),
 only screen and (-o-max-device-pixel-ratio: 3/2),
 only screen and (max--moz-device-pixel-ratio: 1.5),
 only screen and (max-device-pixel-ratio: 1.5) {
  .icon{
    background: url(images/my-icon.png) no-repeat;
  }
}
@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
 only screen and (-o-min-device-pixel-ratio: 3/2),
 only screen and (min--moz-device-pixel-ratio: 1.5),
 only screen and (min-device-pixel-ratio: 1.5) {
  .icon{
    background-image: url(images/my-icon@2x.png);
    /* nouvelle image de 60px par 60px */
    background-size: 30px 30px;
  }
}

On ne débatra pas ici de l’usage fastidieux des préfixes.

La notation “votre-image@2x.png” est ici une convention personnelle et n’est absolument pas obligatoire sur le web, à la différence des applications iOS ou Apple réclame cette nomenclature pour les images Retina.
Espérons que cette norme devienne un jour un standard qui permettra aux navigateurs de détecter ces images à résolution double sans CSS supplémentaire.

Les plus

  • Simple à mettre en place
  • Contrôle de ce qui s’affiche sur chaque type d’écran
  • L’image double sera chargée uniquement pour les écrans à haute densité
  • Possibilité d’utiliser cette technique aussi dans les sprites CSS

Les moins

  • Deux fichiers images par visuel
  • Ne fonctionnera pas sur les anciens navigateurs (IE<9)

Le format SVG

L’emploi du format SVG (Scalable Vector Graphics) pour vos images demande un peu plus de travail mais est aussi plus flexible. Tout comme les formats EPS ou un AI, on a ici une image vectorielle donc dimensionnable à volonté.
Ça semble être la solution idéale. Malheureusement, si l’anti-aliasing fonctionne bien sur les courbes, il pose plus de soucis sur les lignes droites avec l’apparition de “demi-pixels”.

Illustration du crénelage

Source: Simurai

À ce sujet, Simurai propose une méthode pour corriger cet effet. La solution semble alléchante!

Il reste néanmoins un souci majeur: la compatibilité entre navigateurs. En consultant le tableau de Can I Use, vous pourrez vous rendre compte de l’étendue du problème.

Les plus

  • Plus de soucis de résolution
  • Un seul fichier par visuel
  • Les fichiers vectoriels sont souvent plus légers que les fichiers bitmap

Les moins

  • Encore mal supporté par certains navigateurs
  • Plus complexe à utiliser qu’un simple format bitmap
  • Idéal pour des icônes ou des pictos mais pas pour des photos

Les typographies icônes

Très à la mode depuis quelques mois, les typographies dans lesquelles des pictogrammes remplacent les caractères sont une solution plus qu’intéressante. Le concept est simple: se servir du format vectoriel des typographies pour afficher des icônes.

Picto Server

Picto Server fonctionne comme des services tels que Typekit ou FontDeck mais avec une typographie icône

Il en existe des dizaines. À vous de trouver celle qui vous convient le plus, qui est le plus pratique pour votre usage.
En voici une sélection pour exemple: delicious.com/stacks/view/SC3hpq.

Un point important: la sémantique. Pas très bon d’ajouter des caractères indépendants, donc sans valeur sémantique. L’excellent Chris Coyier propose une excellente solution pour les “psychorigides” de la sémantique web.

Les plus

  • Pas besoin de fichier image
  • Dimensionnable à volonté
  • Toutes les propriétés CSS dont on se sert sur les textes sont utilisables

Les moins

  • De solides connaissances dans les logiciels de création de typographies seront nécessaires si vous souhaitez utiliser vos propres icônes
  • Comme il s’agit de typographie, vos icônes seront forcément monochromes
  • Ne fonctionne pas pour les background-image

Les solutions JavaScript

Enfin, il existe quelques solutions JavaScript qui pourront vous venir en aide. Je vous conseille ici deux sites qui proposent des techniques très similaires.

Retina Images: retina-images.complexcompulsions.com
Retina JS: retinajs.com

Le principe est d’utiliser la méthode par Media Queries, comme vue plus haut, seulement la méthode est automatique. Si un écran haute densité est détecté, le script va chercher sur le serveur une version @2x (la nomenclature est ici essentielle au bon fonctionnement). Si cette image existe, elle remplace l’originale.

A noter que Retina Images fonctionne aussi pour les background-image sur le même principe.

Les plus

  • Simple à mettre en place, même sans connaissances JavaScript
  • Seule la bonne image est téléchargée

Les moins

  • Deux fichiers images par visuel
  • Dépendant du JavaScript

A vous de jouer!

L’avenir est clairement dirigé vers les écrans à haute définition et c’est un nouveau paradigme qu’il sera impossible de laisser de côté. En attendant qu’ils deviennent un standard, il nous faut concilier ces grandes différences de résolutions afin d’obtenir les meilleurs rendus possibles.

Il n’existe, à mes yeux, pas encore de solution idéale. Si je devais en choisir une, ce serait probablement les Media Queries pour les icônes et pictos, et Retina Images pour les images de contenu.

J’ai exposé ici cinq techniques pour gérer les écrans à haute densité sur vos sites. En connaissez-vous d’autres? N’hésitez pas à partager vos expériences!

Pour aller plus loin…

A propos de l'auteur : Loris Grillet

Graphiste et webdesigner freelance. Geek suisse, maniaque de typographie et amoureux des pixels. Je dribbble, je tweete, je blogue un peu et je trouve des solutions graphiques, visuelles et techniques pour mes clients.

  • http://twitter.com/chrishrmnn Christophe HERMANN

    Comme très souvent ici, un article très intéressant !

    Des cinq solutions proposées, celle que je trouve la plus intéressante est la dernière. Malheureusement, elle fait appel à un fichier .JS. L’idéal serait que les navigateurs eux même intègre ce procédé : si écran à haute densité -> chercher l’image @2x -> si elle existe, remplacer l’image de base.
    Peut-être que dans le futur, avec l’expansion des écrans de ce type, les navigateurs s’occuperont du problème pour notre plus grand plaisir !

  • zufrieden

    Il y a longtemps :-) nous utilisions l’attribut lowsrc de la balise IMG pour une version light des images en attendant le chargement. On pourrait imaginer un highsrc ou un data-type HTML5.
    Sinon bon article, merci.

  • http://www.web-actually.fr William

    Il existe aussi des solutions côté serveur : http://adaptive-images.com/

  • http://twitter.com/Twikito Matthieu Bué

    Ooh ! J’aime beaucoup cette idée !

  • http://twitter.com/enguerranws Enguerran Weiss

    La question est de savoir: a-t-on vraiment besoin de penser au Retina Display ? Quelle part d’audience cela concerne-t-il pour mon projet ? Quelle sera le désagrément pour cette part d’audience ?
    Le désagrément sera un affichage d’un peu moins bonne qualité des images, et la part d’audience sur ces appareils reste minime…

    Le très bon article de Trent Walton ( http://trentwalton.com/2012/05/08/in-flux/ ) montre qu’on peut aussi s’en tirer avec du CSS.

    Ceci dit, il faudra y passer un jour, mais je pense que d’ici là, les navigateurs l’auront implementé comme l’a dit Christophe.

    Bon article, plein de bonnes choses à piocher.

  • goetter

    Hello, une ouverture vers les débats entre et srcset, pour élargir les horizons futurs aurait été sympa :)

  • http://twitter.com/Twikito Matthieu Bué

    C’est vrai, je pense aussi que ce serait la solution idéale ! :)

  • http://twitter.com/loriskumo Loris Grillet

    Oui c’est vrai que c’est dommage d’être dépendant du JS. Mais il faut aussi se dire que c’est une solution qui améliore le site sans empêcher sa visite aux navigateurs qui ne supportent pas le JS. C’est du “progressive enhacement”.

    Oui c’est un souhait qu’on peut avoir pour la nomenclature @2x. On peut même imaginer que d’ici 5-10 ans, tout le monde sera équipé d’écrans haute densité, que cela soit sur mobile ou sur desktop et que ce genre d’images seront devenues un standard.

  • http://twitter.com/loriskumo Loris Grillet

    Oui, je pense que ça rejoint un peu le principe de et srcset cité par goetter plus bas. Je pense qu’on va y arriver un jour. :-)

  • http://twitter.com/loriskumo Loris Grillet

    Je connaissais cette solution pour le responsive mais il me semble ne pas avoir vu qu’elle supportait le device-pixel-ratio.

  • http://twitter.com/loriskumo Loris Grillet

    Avec les parts de marché grandissantes du trafic web mobile et en sachant que de plus en plus de smartphones utilisent ce genre d’écran, je pense qu’on ne peut pas les laisser de côté. On doit au moins se poser la question de la pertinence de refaire ou non ses images.
    Après bien entendu, on n’est pas obligés de tout refaire non plus, mais je trouve que les icônes, les boutons, les logos, valent au moins la peine d’être retravaillés. :-)

    Pour moi de dire “il n’y a que les gens du métier qui voient la différence” n’est pas la bonne approche. C’est en poussant à chaque fois notre travail un peu plus loin qu’on le devrait qu’il sera meilleur.

    On peut en effet se tirer avec du CSS pur, mais pas dans tous les cas, on a toujours besoin d’afficher des logos, des icônes ou des images. Même si, en effet, on peut faire beaucoup de travail en amont grâce au CSS.

    Merci pour ton commentaire en tout cas. :-)

  • loriskumo

    Oui c’est clair que c’est une musique d’avenir!
    Je me suis concentré ici sur les solutions existantes (je trouve toujours risqué de mélanger l’existant et le supposé dans un article, ça peut porter à confusion), mais c’est clair que ça serait un sujet à aborder! :-)

  • Corinne

    La dernière version prend en compte les écrans haute densité.

  • http://twitter.com/STPo Christophe Andrieu

    Je n’aime pas trop me faire oracle sur les tendances à venir mais je pense que ça va être the next big thing ces nouvelles résolutions d’écran, et pas que sur les téléphones (ça arrive sur Macbook d’ailleurs). C’est beaucoup trop bien (quelle qualité d’image !) pour rester le jouet d’une élite fortunée, ça ne m’étonnerait pas que ça prolifère rapidement.

    Sacré bordel à venir pour nous autres web designers…

  • Pr0xy

    Encore un très bon article, comme d’habitude sur wdf ! C’est vrai que ces histoires d’écrans “rétina”, ça risque de changer notre façon de travailler !

  • http://twitter.com/desbenoit Sébastien Desbenoit

    Super article,

  • http://twitter.com/enguerranws Enguerran Weiss

    Les parts de marché de l’audience web depuis un mobile grandit en effet, celles comportant un retina dispay certainement également (même si, pour ces appareils, les chiffres doivent être pour l’instant assez léger). Bien sûr il faut se poser les questions, faire un peu de prospective.

    Ma réflexion était juste d’un point de vue pratique et presque financier: vu aujourd’hui les solutions pour répondre à ce problème, est-ce que ça vaut vraiment le coup de les mettre en pratique ? Est-ce que le temps passé à vouloir un affichage parfait sur retina display vaut vraiment le temps passé dessus (mis en rapport au bénéfice apporté à ses utilisateurs) ?

    Pour l’instant, je ne pense pas. Quand les solutions techniques seront plus simples à mettre en place, oui, ce sera intéressant. Pour reprendre Trent Walton, dans l’article cité précédemment, les images en 72dpi ont déjà l’air plus jolie sur retina display que sur un écran “normal”.

    Enfin, quand je dis “il n’y a que les gens du métier qui voient la différence”, ça veut dire que le retentissement sur l’utilisateur est minime (voir inexistant). Et moi je fais des interfaces pour les utilisateurs.

    Après oui, en théorie, pour des projets perso et des tests, c’est une question qui m’intéresse bien évidemment et sur lesquels j’ai déjà testé pas mal des solutions proposées sur le web.

    Ceci dit, je pense responsive, et la plupart des techniques actuelles proposées pour avoir un meilleur rendu d’image (qui est déjà très bon même en 72dpi) sur quelques appareils se font au détriment d’autres. Pour celles présentées dans cet article par exemple, il faut s’asseoir sur un certains nombre de principes du RWD pour les mettre en place.

    C’est pour ces raisons que, comme beaucoup, j’attends de meilleures solutions d’implémentation avant de le mettre en pratique dans un vrai projet.

  • http://twitter.com/L_Demontiers Laurent DEMONTIERS

    Merci pour ce memo.

  • http://twitter.com/enguerranws Enguerran Weiss

    Enfin, je suis tout à fait d’accord avec ton point de vue sinon (les retina et autres consorts vont débouler dans tous les sens), il faut essayer, voir ce qui est possible, voir comment ça pourrait être mieux, c’est bien pour ça que je dis ça ! ;)

    Le mieux restant pour moi des solutions de ce type : http://www.w3.org/community/respimg/, en discussion, plutôt que les hacks divers et variés que l’on voit actuellement, et qui vont nous mettre dans la **** à un moment ou à un autre.

    Bref, bon article et bons commentaires, beaucoup de bonnes idées.

  • http://twitter.com/STPo Christophe Andrieu

    Je suis plutôt d’accord avec tout ce que tu viens d’écrire : cible pour le moment faible en volume, multiples hacks imparfaits coûteux en temps et en argent MAIS perspectives intéressantes — j’avais vu cette balise pic chez A List Apart et c’est super bien trouvé, mais franchement connaissant la rapidité des constructeurs et du W3C, on en reparlera dans dix ans…

    Cela étant, je connais des boîtes qui font déjà l’effort aujourd’hui de servir du retina-compliant pour leurs projets en prod (ping @htmlzg), comme quoi c’est un peu maintenant que ça commence à bouger…

  • http://www.loriskumo.com/ Loris Grillet

    Vous avez bien couvert le sujet! Et on en a bien discuté avec Enguerran sur Twitter. :-)

    Si je peux juste rajouter quelques petites choses:
    En effet: quel que soit la solution finalement retenue par le W3C, on ne pourra pas empêcher le fait que les vieux navigateurs ne seront pas compatibles… Après-tout, sur bien des aspects notre travail se résume à une série de “hacks”.
    Toutes les solutions présentées ici (sauf peut-être les fontes icônes, mais le @font-face bénéficie d’un excellent support sur les navigateurs) ont un fallback pour les navigateurs plus anciens. On est vraiment dans de l’amélioration progressive en faisant bénéficier seulement les gens qui peuvent en profiter (sauf les images à 200% ou il faut charger la même image mais ou le rendu est identique).

    Même si cela peut ajouter des coûts supplémentaires, je pense que non seulement cela peut-être une option sur nos devis, mais que cela prove qu’on se soucie du détail. Ça n’est peut-être pas utile pour le site de la Boucherie-Charcuterie du quartier, mais un horloger ou un photographe sera certainement sensible à ce genre de finitions.

    Dernière chose: je trouve que pour les icônes le travail vaut vraiment la peine d’être fait. Les petites icônes (en dessous de 30px) ont vite l’air sale sur un écran Retina si elles ne sont pas retravaillées. Surtout qu’en utilisant les Media Queries on est certain de ne cibler que les utilisateurs à qui cela va profiter.

    En tout cas merci de vos commentaires, le débat est riche!! :-)

  • http://www.loriskumo.com/ Loris Grillet

    Oui, j’ai hésité à en parler d’ailleurs. Mais l’article était déjà bien assez dense! :-)

  • Pingback: “Adapter vos site pour les images Retina” mon article sur le blog WDFriday. | Blog Loriskumo

  • Jerome

    Merci pour cet article très intéressant.

  • Pingback: Adapter vos sites pour les écrans Retina » Webdesign Friday (#wdfr) » Web Design

  • http://twitter.com/dompev dompev

    Très bon article. Avec mon ami John, on parle de ce sujet dans un podcast audio que nous venons de créer. Il est disponible sur notre site http://www.do-jo.net. Si vous êtes intéressé de participer à une de nos futurs émissions, n’hésitez pas à nous contacter via notre site.

  • Pingback: Écrans Retina « Cominmag

  • Jr Atef
  • Carsten

    Merci, article très complet !
    Voici comment gérer simplement les sprites CSS avec cette nouvelle contrainte de densité de pixel :
    http://mobyou.net/blog/2012/10/26/des-fonds-css-haute-resolution/

  • Pingback: « Les vendredis Webdesign » – un site de référence ‹ Lucile Jorland AKA Macbernik

  • Pingback: T42 : le projet qui a pour ambition de faire évoluer le web | PUShAUNE

Live Tweet

Dans le Blog

Newsletter

Vous souhaitez être tenu au courant des dernières nouvelles concernant le WDfriday, événements, conférences, barcamps, etc… ?

N'hésitez pas à vous inscrire à notre newsletter !