Syntaxes prescriptives

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 :

Image de la largeur de l&#39;en-tête d&#39;une fleur pervenche entourée de feuilles et de tiges, visitée par un abeille.

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:

Image largeur d&#39;en-tête d&#39;une fleur pervenche réduite. L&#39;abeille est à peine visible.

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:

Gros plan d&#39;une fleur pervenche en gros plan.

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.