Du Retina et HD pour votre site web : image-set, picture et srcset

Cet article a 2 années. Il commence à dater, lisez-le donc en gardant son âge en tête ! Merci

Retina, ou la haute définition de manière plus générale pour les images de nos sites web pose un problème relatif. En effet depuis la sortie du premier Mac Book Pro à écran Retina (et avant pour certain), la question qui revient le plus souvent est : doit-on boycotter Retina, ou au contraire y accorder de l’importance ?

Je fais partie des gens indécis sur la question, et du coup cette position me va très bien pour écrire cet article, car j’en attends vos réactions.

Pour moi la HD, comme la 3D, fait partie de l’avenir de l’image, que ce soit au ciné, la télévision ou un écran d’ordinateur. C’est comme le son multicanal (plus connu sous le nom de son surround), aujourd’hui ça vous ferait bizarre d’aller au cinéma avec un son mono. Et bien pour la HD c’est pareil, dans quelques années nous ne pourrons plus nous en passer. C’est ce qui me fait dire qu’accorder un minimum d’importance à la HD sur le Web (ici Retina) n’est pas une option.

Voici les problèmes que j’ai pu relever, a priori, en pensant à l’intégration d’images HD :

  • manque de moyens flexibles mis à disposition des développeurs par les fabricants
    • risque de devoir faire de la détection de user agent
    • maintenance du code plus complexe
  • problème de poids des images
    • sites plus lourds en mobilité (Retina sur iPhone4+, iPad, Mac Book)
    • surcharge des serveurs
  • problème de maintenance du site
    • développements plus longs
    • gestion des images et médias plus complexe

Je ne dis pas que cette liste est exhaustive.

Un design nickel chrome

Je n’ai pas mis de majuscule à « chrome » dans le titre, mais j’aurais presque pu.

Bref, blague à part, il y a quelques semaines je vous parlais de l’arrivée de -webkit-image-set() de manière assez concise par ce tweet :

Je vous propose un petit test de cette fonction. Puis nous irons un peu plus loin sur les « images HTML ».

Pour des raisons d’adaptabilité, il m’arrive de plus en plus de placer le logo sur un site web en background CSS, donc pas avec un élément HTML img.
Cette technique me permet de proposer une image légère pour les smartphones et une image plus complexe, grande (et souvent plus lourde) pour des formats plus larges.

De plus si vous regardez un logo classique qui n’a pas subit d’adaptation pour un écran Retina (ou autres HD), il va vous paraitre de moyenne qualité.
Afin de proposer un logo pour Retina sans passer par une media queries, voici un code fonctionnel :

header .logo {
   background-image: url(img/not-supported.png);
   background-image: -webkit-image-set(url(img/logo.png) 1x, url(img/logo-2x.png) 2x);
   background-image: image-set("img/logo.png" 1x, "img/logo-2x.png" 2x, "img/logo-awesome-res.png" 1337dpi);
}

Ici la nouvelle valeur de background-image permet de définir des images sous certaines conditions définies juste après chacune des URL.

J’ai volontairement préfixé uniquement pour webkit car il semblerait que le support ne soit pas (encore) prévu pour les autres navigateurs.
La troisième déclaration de background-image est faite d’après le document en cours de rédaction du W3C sur CSS4 Image. (1337dpi, c’est de l’humour ;))

Cette syntaxe est compatible iOS6 Safari 6 et Chrome 23.
D’après mes tests sous Chrome, seule une image est chargée (chez moi la version « logo.png »).

Images pouvant apparaître dans la démonstration (cliquer pour zoomer)

Démonstration en ligne

Pourquoi image-set et pas media queries ?

C’est une bonne question ! Et en regardant le support de image-set et celui des media queries, la question n’a que plus de force.
Voilà quelques arguments en sa faveur :

  • syntaxe courte
  • permet d’intervenir précisément
  • permet de ne charger que la bonne image tout de suite (testé sur Chrome 23), ce qui n’est pas toujours le cas avec media queries
  • est simplement fait pour ça, et pas autre chose
  • donne un outil en plus des media queries (c’est toujours bien de varier les armes)

Qu’en est-il des « images HTML »

Un groupe de travail est actuellement en train de se tirer les cheveux pour proposer et présenter des solutions possibles pour les images adaptatives.
ResponsiveImages.org

L’élément picture

Cet élément peut, à l’image de l’élément video, accueillir différentes sources.
Ces sources sont utilisées si la condition définie par l’attribut media est respectée.

<picture alt="Texte pertinent">
    <source src="image-small.jpg">
    <source media="(min-width: 20em)" src="image-mid.jpg">
    <source media="(min-width: 40em)" src="image-large.jpg">
    <img src="image-fallback.jpg">
</picture>

La source peut accueillir l’attribut media qui permet de préciser une requête.
C’est une media queries, vous pouvez donc effectuer une requête sur la largeur du viewport, la résolution du device, etc.
L’attribut alt de l’image est porté par l’élément picture et une alternative pour les navigateurs ne supportant pas cette spécification est proposée grâce à l’élément img inséré dans picture.

L’attribut srcset

Cet attribut vient accompagner l’élément img et son attribut src et permet de charger conditionnellement des images.

<img
    src="image-small.jpg"
    srcset="image-mid.jpg 300w, image-large.jpg 2x">

Ici nous avons une image prévue pour les navigateurs qui ne comprennent pas l’attribut srcset (via l’attribut src), puis deux images différentes utilisées selon la condition 300w pour la première (image-mid.jpg) ou 2x, qui correspond à du HD Retina, pour la seconde (image-large.jpg).

Cette syntaxe est partiellement compatible depuis Chrome 34, mais est encore ignorée par les autres navigateurs. Et là où Chrome fait bien son boulot, c’est que seule l’image concernée est chargée. C’est à dire que l’image en src est ignorée si l’un des critères de srcset correspond.

Test et démonstration de srcset

En pratique, il serait possible de définir l’attribut srcset sur une source de l’élément picture également :

<picture>
  <source src="big.jpg">
  <source media="(max-width: 640px)" srcset="small.jpg 1x, small-hd.jpg 2x">
  <img src="fallback.jpg" alt="">
</picture>


srcset n'intervient ici que pour ajouter une condition et une nouvelle source à la première condition définie par l'attribut media.

<update>22/08/2013 : WebKit supporte désormais la syntaxe srcset (source)</update>
<update>09/04/2014 : Chrome 34+ supporte désormais la syntaxe srcset (source), partiellement tout du moins</update>

Mais encore…

Pour ceux qui aiment les choses longues, dures et en anglais, voici un peu de lecture :
HTML Proposals - Responsive images

Sinon il existe aussi une solution partielle avec ce plugin jQuery :
jQuery Responsive img
Plugin a surveiller puisqu'une prochaine version pourrait supporter la HD.

Enjoy !

14 commentaires et un trackback sur “Du Retina et HD pour votre site web : image-set, picture et srcset”

  1. Laurentj dit :
    26 novembre 2012

    >il m’arrive de plus en plus de placer le logo sur un site web en background CSS, donc pas avec un élément HTML img.

    Tu perd en accessibilité, le logo étant tout de même une information. Et tu peux aussi perdre en impression, car, selon la configuration du navigateur, les images de fond peuvent ne pas être imprimées. C’est le cas par défaut dans Firefox (Fait un print preview sur ton site…). On doit alors indiquer d’imprimer les images de fonds. Mais on a alors toutes les images de fond : pour la plupart, c’est de l’information totalement insignifiante (et ça bouffe de l’encre).

    Bref, il n’est vraiment pas recommandé de mettre logo et toutes images significatives en tant qu’images de fond. Et tant pis pour les écrans retina je dirais. Sur le web, l’information prime sur le design !

    • Geoffrey dit :
      26 novembre 2012

      Merci pour ton intervention :)

      « L’information prime sur le design » : je connais trop d’exemples où le design est loin de servir l’information, mais c’est un débat à part.
      Le problème des images non HD sur un écran HD est autant un problème d’accessibilité que de design pour moi.

      Je ne vois pas en quoi je perds en accessibilité si l’information se trouve dans le code HTML.
      J’utilise @media print pour proposer une mise en page sans perte d’information textuelle (on réaffiche le texte au lieu de l’image de fond) et avec le moins d’images possible.

      Après le problème des images, que ce soit CSS ou HTML, si l’utilisateur décide de ne pas les imprimer, c’est une perte d’information, mais un choix de l’utilisateur.

  2. michel v dit :
    26 novembre 2012

    1) Il n’y a pas que le MacBook Pro Retina (ou les iPad 3/4) qui l’ont besoin d’être servis.
    2) Il n’y a pas que Webkit quand on utilise un RMBP, on peut aussi utiliser Firefox dont la version 18 apporte le support HiDPI.
    3) Se reposer sur un brouillon de spec CSS 4, alors que CSS 3 n’est même pas encore totalement là…

    Mon conseil pour supporter la haute définition tout de suite : utiliser des mediaqueries (qui permettent de filtrer sur le dppx) pour les feuilles de style, et du JS comme HiSRC pour gérer les images.

    • Geoffrey dit :
      26 novembre 2012

      @Michel : Bonjour également,

      1) On est d’accord, mais qui a dit ça ?
      2) c’est pour ça que je parle de tests effectués sur Chrome et pas ailleurs,
      3) Je me repose sur des tests et des travaux de recherches officiels pour solutionner des problèmes ; CSS 2, 3 ou 4 m’importent peu.

      HiSRC c’est bien le script qui remplace les images après leur chargement ? Dans ce cas autant ne pas faire appel à JavaScript, ici jQuery en plus, et injecter directement des images plus grand format pour les réduire ensuite… non  ?

      Le fait qu’on ait autant de questions à se poser et d’avis divergents montre bien qu’il y a un manque d’outils réellement efficaces et « natifs », c’est l’objet de cet article ;)

  3. One div dit :
    26 novembre 2012

    Je viens tout juste de sortir un site proposant des icones faites en CSS single element. Malgré des problèmes de compatibilité, cette solution peut s’avérer intéressante au niveau de la problématique du Retina display :). n’hésitez pas à aller faire un tour !

  4. Rémy dit :
    26 novembre 2012

    Je me demande comment les CMS comme WP vont se débrouiller pour intégrer de façon user friendly la gestion des images une fois un élément définitif validé. Déjà que c’est pas forcément évident actuellement, mais avec la gestion des média queries en plus, les lambda vont se perdre

  5. Willy dit :
    26 novembre 2012

    @remy Zut, on allait enfin avoir une galerie des medias enfin un peu plus fonctionnelle ^^

  6. michel v dit :
    27 novembre 2012

    @remy : si je ne m’abuse, Automattic a parlé de support HiDPI transparent pour les blogs WP.com, du coup ça devrait être bientôt dans la version installable de WP. (Suffit d’uploader des images de taille suffisante.)

    @Geoffrey : concernant 1 et 2, mon propos est qu’il faut éviter les solutions qui ne marchent qu’avec Webkit. Pour HiSRC, le comportement est bien plus complexe, cf le code. (En gros ça gère même la detection de bande passante pour servir des images légères pour les téléphones en edge, même si le mediaquery dit que le navigateur supporte le HiDPI.)

    • Geoffrey dit :
      27 novembre 2012

      Hello,

      Merci pour ces informations Michel :)

      Concernant l’utilisation du préfixe -webkit-, je le fais car il est le seul à le comprendre, je ne peux pas en inventer d’autre, et je ne vois pas pourquoi je n’en parlerai pas puisque c’est parfaitement utilisable dans un contexte maitrisé.
      Dans mes projets web mobile, la plupart du temps je m’adresse à 95% d’utilisateur iTruc, je fais donc de l’amélioration progressive à moindre coût (en temps et en performance), et ça n’empêche en rien la navigation sur le site des 5% restant.

      Bonne journée.

  7. 2 décembre 2012

    Merci pour cet article. Permet de mieux comprendre l’intégration des images HD.

    Ces problèmes de poids sont temporaires, enfin j’espère, si la 4G se démocratise rapidement, on aura des débits supérieurs à l’ADSL sur mobile !

    Donc fini les soucis de chargement.

    • Geoffrey dit :
      2 décembre 2012

      @Julien : Si c’est comme avec le WIFI ou 3G de maintenant, la connexion aura bien le droit à quelques faiblesses assez fréquentes. Autant ne distribuer que les bonnes images :) D’ici là réseaux et solutions auront fait un bout de chemin vers l’optimisation !

  8. LuciferX dit :
    2 décembre 2012

    Intéressant cet article, étant justement à la recherche de techniques pour concilier responsive et retina, je suis tombé sur cet article qui présente aussi la solution « picture » et qui me semble plus complet pour une rétro-compatibilité entre navigateurs: http://cyril-wolfangel.com/integrateur-typo3/2012/08/05/image-responsive-enfin-une-solution-perenne/

    Jusqu’à présent, il ùe semble que c’est la meilleure technique que j’ai pu trouver.

    • Geoffrey dit :
      2 décembre 2012

      Article bien complet, merci pour la référence, je l’ajoute dans les liens en fin de billet :)

  9. 3 décembre 2012

    @geoffrey : les systèmes sont prévus pour basculer en 3G+ dans ce cas mais tu as raison mieux vaut prendre des précautions

Laisser un commentaire

Certains codes HTML ne sont pas échappés automatiquement. Pour afficher du code dans votre commentaire, merci d'échapper vos chevrons en utilisant "&lt;" et "&gt;" en lieu et place de "<"" et ">".

Il est difficile de proposer un support pour tous les articles de ce blog. En ne fournissant pas un moyen de consulter votre code bogué, vous vous assurez de ne pas avoir de réponse adaptée. Utilisez CodePen.io à défaut d'une page web.

Les sites qui en parlent

 
Le studio web