Le HTML du futur : changer la source d’un flux vidéo depuis une intégration native

À force de faire l’éventail des possibles avec HTML, j’en viens à rêver. Il en ressort, je crois, quelques bonnes idées que j’ai envie de partager plus largement qu’en formation. J’entame donc une série d’articles courts intitulée : « Le HTML du futur ». Veuillez noter que l’objectif n’est pas de couvrir l’évolution réelle du langage — du moins, pas de façon intentionnelle. Il s’agit plutôt d’envisager des pistes crédibles permettant d’aller encore plus loin dans l’écoconception technique de nos services numériques.

Premier volet !

Code de démonstration pour une intégration vidéo native efficace

<video preload="none" poster="/path/to/poster.webp" controls>
	<source src="/path/to/1080p.webm" type="video/webm" media="(min-height: 1080px) and (min-width:1920px)">
	<source src="/path/to/1080p.m4v" type="video/mp4" media="(min-height: 1080px) and (min-width:1920px)">
	<source src="/path/to/720p.webm" type="video/webm" media="(min-height: 720px) and (min-width:1280px)">
	<source src="/path/to/720p.m4v" type="video/mp4" media="(min-height: 720px) and (min-width:1280px)">
	<source src="/path/to/360p.webm" type="video/webm">
	<source src="/path/to/360p.m4v" type="video/mp4">
	<track kind="subtitles" label="Français" src="/path/to/subtitle-fr.vtt" srclang="fr" />
	<track kind="subtitles" label="English" src="/path/to/subtitle-en.vtt" srclang="en" />
</video>

Dans cet exemple :

• L’attribut preload bloque le préchargement de la vidéo sinon chargée par défaut ;
• L’attribut poster définit une image de prévisualisation (ici, en WebP) ;
• L’attribut controls permet à l’utilisateur d’accéder aux contrôleurs (lecture, volume, etc.) ;
• Les éléments <track> listent deux pistes de sous-titres disponibles à la demande (fr, en).
• Les éléments <sources> listent plusieurs flux pour tenir compte du support du navigateur web en matière de format, mais aussi de la résolution de l’écran de l’utilisateur lors du chargement de la page (sélection par le navigateur Web).

Ce bout de code que je montre en formation « Développer des sites web écoresponsables et conformes au RGESN » est un excellent point de départ pour diffuser de la vidéo de façon plus responsable.

Mais en tire-t-on vraiment tous les bénéfices ?

Qu’est-ce qui coince ?

Tout dans le titre (h1) : il manque la possibilité de changer la source du flux vidéo depuis le lecteur natif. Car à date, s’il est possible de proposer plusieurs sources, une seule d’elles sera choisie, par le navigateur web, jamais par l’utilisateur. Un faux problème ? Après tout, à en croire tout ce que j’ai écrit plus haut, le navigateur web est censé choisir la plus pertinente.

Et c’est vrai.
Mais : et l’utilisateur, dans tout ça ?

1. Admettons que Martin dispose d’un écran Full HD (1080p). La vidéo sélectionnée par le navigateur web est dans tous les cas « /path/to/1080p.webm » si le support de WebM est assuré, sinon « /path/to/1080p.m4v ».
2. Cependant, Martin ne souhaite pas passer à une diffusion en plein écran. Il se contente de regarder la vidéo dans l’intégration de la page (dimensions variables selon l’interface, avec un rendu de l’ordre de 360 x 640 pixels). Lire du 1920 x 1080 pixels, c’est donc trop.
3. De plus, comme Martin est sensible aux impacts environnementaux du Numérique, il abaisserait volontiers de lui-même la qualité de la vidéo si on lui en donnait les moyens. Or l’option en question n’existe pas.

Alors que toutes les sources utiles sont à disposition !

Qu’est-il possible de faire en tant que dev’ ?

Pour information, l’élément <video> dispose :

• D’une méthode load pour charger un flux différent du précédent à la demande ;
• D’une propriété currentTime pour récupérer la progression actuelle, et donc poursuivre la lecture exactement au même moment, y compris après changement de source ;
• D’une méthode play pour relancer la lecture le moment opportun.

Changer à loisir de vidéo en JavaScript, c’est facile. Seulement voilà : on ne peut pas étendre les contrôleurs par défaut de notre élément video. Soit on fait avec ce qu’on a, soit il faut tout reprendre à zéro. Et si je peux comprendre l’intérêt (éviter les dérives), cette rigidité est aussi un vrai frein à l’exploitation du natif.

Qu’attend-on de HTML à l’avenir ?

Vraiment pas grand-chose !

À mon sens, tout (ou presque) est prêt dans le code que j’écris plus haut pour donner à l’utilisateur un peu plus de contrôle à ce sujet.

Voici comment j’imagine la mise en œuvre :

• Ajout d’un attribut spécifique à l’élément video. L’objectif est de pouvoir spécifier si l’on souhaite ou non permettre à l’utilisateur de choisir parmi les sources disponibles.
• OU, approche inverse, proposer une telle option par défaut, désactivable avec controlslist qui existe déjà pour limiter les contrôleurs disponibles (téléchargement, plein écran…).
• Dans les deux cas : l’utilisateur dispose d’un bouton dédié à l’action. À noter que dans le meilleur des mondes, pour notre exemple, le navigateur web liste uniquement WebM si support, sinon MP4, de façon à éviter toute confusion côté utilisateur (l’attribut type respectif à chaque élément <source> est propice à cela).
• Reste un manque : identifier et restituer les définitions disponibles. Car à moins de charger chaque ressource (contreproductif), je ne pense pas que le navigateur web puisse déterminer de lui-même chaque définition. Ceci peut être facilement corrigé avec la création d’un attribut dédié en élément source. Rien d’insurmontable.

Pour en savoir plus sur où on est aujourd’hui, n’hésitez pas à consulter les documentations suivantes sur la MDN Web Docs :

• élément <video>
• élément <source>