Ce billet fait partie de la série en <img /> :

1. Histoires en <img />
2. Manuel en <img />
3. Ressources en <img />
4. Bricolages en <img />
5. Progressivement en <img />
6. Finesse en <img />
7. Propositions en <img /> / English version

On va aborder la balise <img /> dans sa sémantique en analysant ses attributs passés, présents et peut-être futurs.
Pour les fans du TL;DR, cette table leur fera oublier qu'ils ont jamais remarqué le lien Sommaire de ce billet sous le résumé ^^

Oui, il n'y a pas tout, puisque ce billet n'a pas pour but d'être exhaustif, mais de farfouiller et d'annoter ce qui s'est fait. J'ai donc volontairement écarté les attributs purement “design” (align="", hspace="", vspace="", border="") relevant de la CSS.

Quand même, soyons sérieux.
Quant à srcset="", il mérite vraiment son chapitre à part tellement que les charges sont lour non je vais pas spoiler son affaire ;)

Pour illustrer les exemples, j'ai pris une carte des régions de France parce que quand j'ai commencé cette suite d'article, j'ignorais que Manuel Valls avait mis dans son programme gouvernemental la réforme de cette ressource Wikimédia...

width="" et height=""

Il fut une époque où les modems étaient tellement lents que l'image d'une page pouvait se charger après plus d'une minute. Il est encore une époque où des rigolos mettent des images distantes dans leurs e-mails en html, et qui par défaut ne sont plus chargées automatiquement. Pour éviter des sautes d'affichages à la lecture (aujourd'hui, nous dirions repaint), on indiquait la dimension de l'image attendue avec les attributs width="" et height="". Un espace blanc, élégamment cerné de noir et d'une icône d'image indiquait qu'une illustration allait arriver.

…peut-être…

…bientôt…

Le principal souci de ces attributs est que la transformation homothétique n'est pas forcément explicite (cela ne marche que si un seul des attributs est mis, et encore…). Et comme à l'époque, il était très rare de trouver des scripts qui transforment les tailles des images côté serveur. On avait donc un usage qui amenaient à de mauvaises pratiques : la sur-résolution.
Combien de fois avez-vous eu des clients qui envoyaient des images de 2000×1600 pixels, qui étaient “réduites” en front avec width="100" height="100" ? En plus de mélanger bêtement présentation et sémantique, ces attributs avaient aussi le souci de la mise à jour des ressources : Si l'image était mise à jour, il était pas rare que les dimensions dans les balises qui l'appelaient n'étaient plus bonnes, donnant un aspect distordu. Surtout qu'à l'époque, les algorithmes des navigateurs pour redimensionner par interpolation étaient assez… rudes… C'était vraiment pas beau.

Oui, ces attributs avaient disparus pour de bonnes raisons, mais quelqu'un a dit Time And Relative Dimension In Space et elles sont revenues, entre autres pour la balise <svg></>, et aussi pour la sur-résolution.

D'une manière ironique, nous revenons à ces pratiques de sur-résolutions en css pour gérer les navigateurs aux rendus à haute-densité (high-DPI comme disent les pros, Retina™ comment disent les appeuleumaniaques), car l'autre solution c'est faire du javascript à foison pour découvrir via window.devicePixelRatio quelle est la différence de taille entre les pixels physiques et les pixels logiques. Oui, c'est à devenir fou.
Un exemple de méthode de sur-résolution est de prendre une image exportée en jpeg à un taux de compression plus agressif (genre 70%), mais deux fois plus grand que la dimension souhaitée, et de la réduire avec height="50%".
Scandaleux…? Je parlerai de srcset="" plus tard.

longdesc=""

longdesc="" doit renvoyer vers une page html qui comporte une description complète du document. Par exemple, si on prend la carte de France, quand elle est citée dans la Wikipédia, elle peut (ce n'est pas systématiquement le cas) comporter cet attribut avec un lien vers la page descriptive correspondante sur Wikimedia. En fait, selon une étude de 2007 du WHAT-WG sur la pertinence de cet attribut, il est noté que les sites Wikipedia et ceux basés sur son CMS MediaWiki sont les consommateurs quasi-exclusifs de cet attribut.

Pour la carte de France choisie en exemple, le code devrait être :
<img src="http://dascritch.net/…/.1404-Img-CarteDeFrance_m.png" longdesc="http://commons.wikimedia.org/wiki/File:France_fond_de_carte_27_r%C3%A9gions.png" …

Étonnement, cet attribut devrait plus être utilisé comme métadonnée pour l'indexation et la gestion documentaire. Mais à relire le standard actuel, il y est plus décrit comme un élément d'accessibilité.

Et justement, en termes d'accessibilité, cet attribut s'est montré catastrophique. Dans une discussion du groupe de travail de feu-XHTML2, un des participants fait remarquer que le logiciel de lecture d'écran JAWS ouvre le contenu de longdesc dans une fenêtre à part, ce que les bloqueurs de pop-up bloquent !

À l'usage, cet attribut tombe dans tous les défauts des métadonnées séparées de leur contenu : sa maintenance est souvent oubliée donnant ainsi des informations erronées si elle n'est pas automatisée. Dans ce cas, MediaWiki fait un excellent boulot en proposant le versionning, les origines du documents, les url locales y faisant référence et un décodage des métadonnées embarquées dans l'image (Tiens, ça donne de super idées de plugin pour dotclear, ça…).
Et si on pourrait croire que cette balise est taillée pour la Wikipedia, c'est faux ! Dans l'esprit du législate normalisateur, l'idée qu'il avait était de proposer une description de l'image plus longue que la balise alt="". Par exemple, si votre image représente un camembert de données ou des graphes, le longdesc devrait pointer vers un document proposant le tableau originel de données.

L'usage recommandé est de l'oublier et de plutôt s'intéresser à l'attribut aria-describedby="". La valeur attendu par cette balise est l'id d'un élément de la page, très probablement son <figcaption> </> si vous avez utilisé cette structure. Comme ceci :
<figure>
   <img src="http://dascritch.net/…/.1404-Img-CarteDeFrance_m.png" aria-describedby="figdescription" alt="[…]" />
   <figcaption id="figdescription">…

ÀMHA une telle structure est inutilement verbeuse si justement on utilise le balisage sémantique <figcaption> </>…

lowsrc=""

J'explique en détails le fonctionnement de cet attribut dans le chapitre consacré au chargement progressif.

lowsrc="" permet le chargement rapide, en attendant la grooooosse ressource. C'est une fonctionnalité tellement obsolète qu'on peut dire qu'elle est désuète voir qu'elle n'existe plus. Bon, certains ne sont pas encore au courant, mais de la part de sites comme W3Schools, vous vous attendiez à quoi ?

Ceci dit, si nous avons la possibilité d'utiliser le stylage en css pour mettre une image le temps de charger la ressource, il est difficile d'appliquer cette solution individuellement pour chaque balise. Oui, bien sûr qu'on peut avec style="background-image:url(…, mais vous ne ressortiriez pas vivant de cette pièce si je vous y surprend…

ismap=""

Cet attribut était une idée de bidouillage : celui de passer la zone cliquée sur une image, quand elle est embarquée dans un lien. Les paramètres sont passés alors en paramètres GET dans la cible du lien, et donc doivent être traités par le serveur. Je vous invite à voir ce que ça fait en dessous :

Comme vous pouvez le voir en survolant à la souris ou en cliquant l'image, la cible du lien est alors complété par deux paramètres GET, séparés par une virgule et sans association. On a donc un lien http://cible?abcisse,ordonnée. Par exemple, si je clique (vaguement) sur Toulouse, j'ai un #attr_ismap?210,320. Si vous aviez prévu d'utiliser d'autres paramètres GET dans le lien, vous êtes marrons.

Ce système ne s'est pas montré très heureux à l'usage. Le simple fait que la gestion du point géométrique appuyé soit géré côté serveur en rendait sa maintenance très peu aisée ; l'attribut usemap="" s'est montré plus simple, car la définition des zones est alors remontée côté client.

usemap=""

Selon les standards d'accessibilité, ismap="" doit être remplacé par usemap="". Cet attribut a une particularité : il ne doit pas être utilisé dans une <img /> fille d'un <a href=""> ou d'un <button>. Oui, à l'inverse de ismap=""… Dans les faits, je m'en sers même pas.

La valeur de l'attribut est notée comme un adressage id (c'est-à-dire commençant par un #), mais est posée par un name="". Ce qui n'est absolument pas la même chose. L'élément pointé est une balise bloc <map name=""></> qui contient un ensemble de balises <area shape="" href="" /> décrivant des zones géométriques et les liens qui leur sont associés. Voici justement l'exemple pour l'exemple du dessous :

Le lien est un vrai lien indépendant avec une url complète. La description de <map></> et des <area /> étant très complexe, je vous laisserai lire la doc idoine sur le sujet. De sa version d'origine (HTML 3.2) à la plus récente. À noter que les zones acceptent l'attribut title="", que les vieux qui en sont à l'informatique point'n'click non-digitale (donc à la souris) verront les informations en survolant l'image de démo ci-dessous :

À toi qui me lit, sache que oui, cet attribut m'a fait adorer Dreamweaver de Macromedia. Au nombre de fois que j'ai fais du détourage de zone avec cet outil, je peux t'assurer qu'il m'a sauvé au moins 3 après-midi. Et je le dis sans honte : En cette époque obscure où le style était dans les attributs, la mise en page en tables et les interactions dans des <a href="javascript:…, on n'avait pas mieux.
On était en 2000, et depuis j'ai appris à m'en méfier.

Au final, aucun de ces deux attributs ne furent pérennes. Les différents remplacements en javascript se sont montrés bien meilleurs et inclure du svg via notation xhtml ou plus tard par la balise <svg></> dans le html s'est montré largement plus pratique et prometteur.
Imagineriez-vous encore une carte à la google map qu'avec des liens cliquables ?

crossorigin=""

Si vous servez votre site en protocole https:// et que la source de votre image n'est pas sur le domaine, les mesures prophylactiques du navigateur lancera une alerte, soupçonnant votre site d'être injecté ou corrompu. Ou alors ignorera la source et donc n'affichera que le alt="". À moins que vous ayez déclaré en entête http (HSTS et CSP) que le site externe fait partie des ressources autorisées, vous pouvez encore le faire après coup

Sur le terme sécu, cela ne protège en rien d'une injection. Je trouve même cette balise comme contre-productive : il ne faut jamais faire de hot-link vers un site que vous ne maîtrisez pas. Quand je vois qu'un site à fort traffic a fait un lien direct vers une image, je remplace à la volée la ressource par un truc ignoble qui devrait faire fuir tout le monde. Et je vous encourage à en faire de même.

alt=""

L'attribut alt="" est strictement obligatoire pour la moindre <img />, mais pas mandatoire.

Cet attribut a pour charge de proposer un contenu alternatif (eh oui) si la ressource met du temps à être chargée, si elle est inutilisable ou si le client web ne peut afficher d'image. Ce dernier point fait qu'il est très utile voire primordial : les synthèses vocales, les tablettes brailles, la plupart des crawlers et les navigateurs en mode texte vont s'en servir. Il y a donc un réel intérêt à le renseigner, plutôt qu'entendre un image quand elle n'y est pas (thank you, captain obvious).

La manière d'écrire son contenu a longtemps été sujet à des discussions sans fins, et il est enfin proposé par le W3C des recommandations, claires pour la plupart des cas de figures, allant du logo contenu un texte, un diagramme ou une illustration qui accompagne un texte.

D'où ma question :
maintenant que nous maîtrisons les CSS pour ne plus appeler d'images à tort et à travers, que nous avons les webfonts ce qui permet de répondre aux demandes client de “design” les plus farfelues, et le svg pour aller encore plus loin... nous n'utilisons plus que alt="" pour du réel contenu, les images appelées représentent très rarement du texte écrasé. Bref, nous laissons le contenu vide.
De nos jours, alt="" est réellement important pour l'accessibilité, mais nous mettons de plus en plus souvent un contenu vide. Est-il temps de faire évoluer les navigateurs et de proposer qu'alt="" soit implicite ?

Je sais qu'il y aura toujours le problème de l'existant, mais n'est-il pas temps de commencer ?

src=""

src="" appelle la ressource. Évidemment, cette balise est obligatoire.

Celle-ci peut-être une URL, locale ou distante, ou alors une ressource interne, comme pour les e-mails ou dans certains cas des emoji (mais c'était une méthode propriétaire d'un monde révolu, oubliez-le). À noter que dans les URL possibles, il y a le mode data:[…] qui permet d'embarquer dans l'URL le contenu de la ressource. Honnêtement, je ne le recommande pas des masses.

De toutes les balises audiovisuelles, c'est la seule qui contrairement à ses collègues comme <audio></>, <video></> ou <object></>, ne supporte pas de gestion de dégradation élégante native, ou fallback, c'est-à-dire d'une solution de repli à part afficher le contenu de l'attribut alt="". Cela est dû à la nature auto-fermante de la balise, un peu comme <embed /> et raison principale pour laquelle je déconseille toujours d'utiliser cette dernière.

Il y a actuellement des propositions de normalisation, principalement pour une gestion native du High-DPI (ce qui est commercialement appelé un écran Retina™). Le problème est que le débat sur sa syntaxe n'arrive pas à obtenir à la fois un consensus rétro-compatible et futureproof à l'épreuve du temps. Personne n'est convaincu par les propositions actuelles. D'ailleurs, l'objet DOM ne propose pas de méthode de support de contenu, là ou <audio></> ou <video></> permettent de savoir si le navigateur supporte un codec particulier comme ogg vorbis ou h264. Ben non, impossible de le deviner avec <img></>, sinon en chargeant une image à un format, et de tester en javascript si elle a été chargée, affichée ou non.

C'est une contrainte importante à savoir si vous décidez de pointer une ressource dans un format qui n'est supporté que marginalement. Et j'en parlerai justement dans le prochain chapitre.