L'élément <picture>
n'affiche rien de lui-même, mais sert de moteur de décision pour un élément <img>
interne.
lui indiquant ce qu'il doit afficher. <picture>
suit un précédent déjà défini par les éléments <audio>
et <video>
: un élément wrapper.
contenant des éléments <source>
individuels.
<picture>
<source …>
<source …>
<img …>
</picture …>
Ce <img>
interne vous fournit également un modèle de remplacement fiable pour les navigateurs plus anciens qui ne prennent pas en charge les images responsives:
Si l'élément <picture>
n'est pas reconnu par le navigateur de l'utilisateur, il est ignoré. Les éléments <source>
sont ensuite également supprimés.
car le navigateur ne les reconnaîtra pas du tout ou n'aura pas de contexte pertinent pour eux sans parent <video>
ou <audio>
.
Toutefois, l'élément <img>
interne sera reconnu par n'importe quel navigateur, et la source spécifiée dans son élément src
s'affichera comme prévu.
"Direction artistique" images avec <picture>
La modification du contenu ou des proportions d'une image en fonction de la taille de l'image sur la page est généralement appelée "direction artistique".
des images responsives. srcset
et sizes
sont conçus pour fonctionner de manière invisible : ils changent de source en fonction du navigateur de l'utilisateur.
Toutefois, il peut arriver que vous souhaitiez modifier les sources entre les points d'arrêt afin de mieux mettre en évidence le contenu, de la même manière que vous adaptez les mises en page.
Par exemple, une image d'en-tête pleine largeur avec un petit focus central peut s'avérer efficace sur une grande fenêtre d'affichage :
Toutefois, si la taille de l'image est réduite pour l'adapter aux fenêtres d'affichage de petite taille, l'attention principale de l'image risque d'être perdue:
Le sujet de ces sources d'image est le même, mais pour mieux faire la mise au point sur ce sujet visuellement, vous devez les proportions de la source de l'image à changer entre les points d'arrêt. Par exemple, effectuez un zoom plus rapproché sur le centre de l'image. certains détails au niveau des bords ont été rognés:
Ce type de "recadrage" peut être réalisé via CSS, mais l'utilisateur demanderait toutes les données qui composent cette image, même s'ils ne la voient peut-être jamais.
Chaque élément source
comporte des attributs qui définissent les conditions de sélection de ce source
: media
, qui accepte un
média query et type
, qui accepte un type de média (auparavant appelé "type MIME"). Le premier <source>
de la source
pour correspondre au contexte de navigation actuel de l'utilisateur est sélectionné, et le contenu de l'attribut srcset
sur ce source
permet de déterminer les candidats appropriés pour ce contexte. Dans cet exemple, la première source
avec un attribut media
correspondant à la taille de la fenêtre d'affichage de l'utilisateur est celle sélectionnée:
<picture>
<source media="(min-width: 1200px)" srcset="wide-crop.jpg">
<img src="close-crop.jpg" alt="…">
</picture>
Vous devez toujours spécifier le img
interne en dernier dans l'ordre, si aucun des éléments source
ne correspond à ses media
ou type
l'image fait office de "par défaut" source. Si vous utilisez min-width
requêtes média, vous devez avoir la plus grande
sources en premier, comme dans le code précédent. Lorsque vous utilisez des requêtes média max-width
, vous devez placer la plus petite source en premier.
<picture>
<source media="(max-width: 400px)" srcset="mid-bp.jpg">
<source media="(max-width: 800px)" srcset="high-bp.jpg">
<img src="highest-bp.jpg" alt="…">
</picture>
Lorsqu'une source est choisie en fonction des critères que vous avez spécifiés, l'attribut srcset
de source
est transmis à la
<img>
comme si elle avait été définie sur <img>
, ce qui signifie que vous êtes libre d'utiliser sizes
pour optimiser l'image orientée artistique
sources.
<picture>
<source media="(min-width: 800px)" srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w">
<source srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w">
<img src="fallback.jpg" alt="…" sizes="calc(100vw - 2em)">
</picture>
Bien entendu, une image dont les proportions peuvent varier en fonction de l'élément <source>
sélectionné pose un problème de performances:
<img>
n'accepte qu'un seul attribut width
et height
, mais l'omission de ces attributs peut entraîner une expérience utilisateur nettement inférieure.
Pour tenir compte de cela, une étude relativement récente, mais
correctement compatible, en plus du code HTML
permet d'utiliser les attributs height
et width
sur les éléments <source>
. Ils permettent aussi de réduire
les décalages de mise en page
comme pour <img>
, avec l'espace approprié réservé dans votre mise en page pour l'élément <source>
sélectionné.
<picture>
<source
media="(min-width: 800px)"
srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w"
width="1600"
height="800">
<img src="fallback.jpg"
srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w"
sizes="calc(100vw - 2em)"
width="1200"
height="750"
alt="…">
</picture>
Il est important de noter que la direction artistique ne se limite pas à prendre des décisions basées sur la taille de la fenêtre d'affichage. Cela doit être le cas, étant donné que
la majorité de ces cas peuvent être traités plus efficacement avec srcset
/sizes
. Par exemple, choisir une source d'image mieux adaptée
adapté au jeu de couleurs dicté par les préférences de l'utilisateur:
<picture>
<source media="(prefers-color-scheme: dark)" srcset="hero-dark.jpg">
<img srcset="hero-light.jpg">
</picture>
Attribut type
L'attribut type
vous permet d'utiliser le moteur de décision de demande simple de l'élément <picture>
pour ne diffuser que des formats d'image
aux navigateurs compatibles.
Comme vous l'avez appris dans la section Formats et compression d'images, un encodage que le navigateur ne peut pas analyser n'est même pas reconnaissable, données d'image.
Avant l'introduction de l'élément <picture>
, les solutions front-end les plus viables pour diffuser de nouveaux formats d'image nécessitaient
le navigateur demande et tente d'analyser un fichier image avant de déterminer s'il doit être jeté et chargé d'une création de remplacement. A
Voici un exemple de script courant:
<img src="image.webp"
data-fallback="image.jpg"
onerror="this.src=this.getAttribute('data-fallback'); this.onerror=null;"
alt="...">
Avec ce format, une requête pour image.webp
serait tout de même effectuée dans tous les navigateurs, ce qui signifie un transfert inutile pour les navigateurs.
sans WebP. Les navigateurs qui ne pouvaient ensuite pas analyser l'encodage WebP généraient un événement onerror
, puis échangeaient
la valeur data-fallback
en src
. C'était une solution gaspillage, mais là encore, des approches comme celle-ci étaient la seule option
disponibles sur l'interface. N'oubliez pas que le navigateur commence à demander des images avant qu'un script personnalisé
de s'exécuter, ou même d'être analysés,
et nous n'avons donc pas pu préempter ce processus.
L'élément <picture>
est explicitement conçu pour éviter ces requêtes redondantes. Même s'il n'y a toujours pas
moyen pour un navigateur
pour reconnaître un format non compatible sans le demander, l'attribut type
avertit le navigateur de la source.
les encodages en amont, afin qu’il puisse
décider d’effectuer ou non une requête.
Dans l'attribut type
, vous indiquez le type de média (anciennement "type MIME").
de la source de l'image spécifiée dans l'attribut srcset
de chaque <source>
. Le navigateur obtient ainsi toutes les informations qu'il
doit déterminer immédiatement si l'image candidate fournie par ce source
peut être décodée sans créer de
requêtes : si le type de support n'est pas reconnu, <source>
et tous ses candidats sont ignorés, et le navigateur continue.
<picture>
<source type="image/webp" srcset="pic.webp">
<img src="pic.jpg" alt="...">
</picture>
Ici, tous les navigateurs compatibles avec l'encodage WebP reconnaîtront le type de contenu image/webp
spécifié dans l'attribut type
.
de l'élément <source>
, sélectionnez ce <source>
et, comme nous n'avons fourni qu'un seul candidat dans srcset
, indiquez la valeur
<img>
pour demander, transférer et afficher pic.webp
. Tout navigateur non compatible avec WebP ignorera le source
, et
En l'absence d'instructions contraires, <img>
affichera le contenu de src
comme c'est le cas depuis 1992.
Bien entendu, vous n'avez pas besoin de spécifier un deuxième élément <source>
avec type="image/jpeg"
. Vous pouvez supposer que le format JPEG est compatible avec tous les formats.
Quel que soit le contexte de navigation de l'utilisateur, tout cela est réalisé avec un seul transfert de fichier, et aucune bande passante n'est gaspillée sur
sources d'images qui ne peuvent pas être affichées. Cette approche est également tournée vers l'avenir: avec l'arrivée de nouveaux formats de fichiers plus efficaces,
avec leurs propres Media Types. Nous pourrons en profiter grâce à picture
, sans JavaScript ni côté serveur.
les dépendances, et toute la vitesse de <img>
.
L'avenir des images responsives
Tous les schémas de balisage abordés ici représentaient un gros effort en termes de standardisation: la modification de la fonctionnalité
quelque chose d'aussi bien établi et au cœur du Web (<img>
) n'a pas été une mince affaire, et la série de problèmes visés par ces modifications
étaient complexes, voire incontournables. Si vous vous êtes pris en train de penser qu'il était possible de s'améliorer avec ces
des modèles de balisage, vous avez tout à fait raison. Dès le départ, ces normes visaient à fournir une base de référence
sur lesquelles s'appuyer.
Toutes ces solutions dépendent nécessairement du balisage pour être incluses dans la charge utile initiale du serveur.
et arrivent à temps pour que le navigateur demande les sources des images, une limitation qui rendait l'attribut sizes
difficile à manier.
Cependant, depuis que ces fonctionnalités ont été introduites sur la plate-forme Web, une méthode native de report des requêtes d'image a été introduite.
Les éléments <img>
avec l'attribut loading="lazy"
ne sont pas demandés tant que la mise en page de la page n'est pas connue, afin de différer
les demandes d'images en dehors de la fenêtre d'affichage initiale de l'utilisateur jusqu'à un stade ultérieur du processus d'affichage de la page, ce qui peut éviter
des requêtes inutiles. Comme le navigateur comprend parfaitement la mise en page au moment où ces requêtes sont effectuées,
L'attribut sizes="auto"
a été proposé en complément de la spécification HTML
pour éviter la corvée des attributs sizes
écrits manuellement dans ces cas.
L'élément <picture>
a également été ajouté à l'horizon pour répondre à des modifications particulièrement intéressantes.
à la façon dont nous stylisons les mises en page. Bien que les informations de la fenêtre d'affichage constituent une base solide pour prendre des décisions de mise en page de haut niveau, elles
nous empêche d'adopter une approche du développement entièrement au niveau des composants, c'est-à-dire un composant qui peut être intégré
n'importe quelle partie d'une mise en page, avec des styles qui réagissent à l'espace occupé par le composant lui-même. Ce problème a conduit
à la création de requêtes de conteneur, une méthode de stylisation des éléments
en fonction de la taille de leur conteneur parent, et non de la fenêtre d'affichage seule.
Alors que la syntaxe des requêtes du conteneur vient tout juste de se stabiliser et que la compatibilité des navigateurs est très limitée,
au moment de la rédaction de ce document. L'ajout des technologies de navigateur qui l'activent fournira à l'élément <picture>
une
cela signifie de faire la même chose: un attribut container
potentiel qui permet de définir des critères de sélection de <source>
en fonction du
occupe l'espace occupé par <img>
de l'élément <picture>
, plutôt que de dépendre de la taille de la fenêtre d'affichage.
Cela peut vous sembler un peu vague, et ce n'est pas pour rien: ces discussions sur les normes du Web sont en cours, mais sont loin d'être réglées. ne peuvent pas encore les utiliser.
Si le balisage d'image réactif promet de devenir de plus en plus facile à utiliser au fil du temps, comme n'importe quelle technologie Web, il existe un certain nombre de services, de technologies et d'environnements pour vous faciliter la tâche en écrivant manuellement le balisage disponible. Dans le module suivant, nous verrons comment intégrer tout ce que nous avons appris sur les formats d'image, la compression et les images responsives dans un workflow de développement moderne.