Apple propose d'ajouter un élément <model> au HTML pour afficher du contenu en 3D
Apple propose d'ajouter un élément <model> au HTML pour afficher du contenu en 3D
et faciliter son intégration dans les pages Web
Les contenus audios et vidéos sont devenus incontournables sur le Web avec l'avènement des plateformes de médias sociaux, mais d'autres types de contenus comme la 3D, commencent à se démocratiser et pourraient représenter l'avenir du Web. Comme à son habitude, Apple veut être l'un des pionniers de cette révolution et propose d'ajouter l'élément <model> au HTML pour afficher du contenu en 3D. Le fabricant de l'iPhone explique que l'élément HTML <model> vise à permettre à un site Web d'intégrer des modèles 3D interactifs aussi facilement que tout autre média visuel.
Apple veut rendre plus facile l'affichage des médias 3D sur le Web
Le HTML est le langage de balisage conçu pour représenter les pages Web. Il permet l'affichage de plusieurs types de médias par le biais d'éléments tels que <img>, <picture> ou <video>, mais il ne fournit pas de manière native pour consommer directement du contenu 3D. L'intégration d'un tel contenu dans une page est relativement lourde et repose sur l'utilisation d'un script pour l'élément <canvas>. « Nous pensons qu'il est temps de mettre les modèles 3D sur un pied d'égalité avec les autres types de médias, déjà pris en charge », a déclaré Apple à propos de la nouvelle balise.
L'élément <model> est le travail des ingénieurs Antoine Quint, Dean Jackson et Theresa O'Connor d'Apple. Selon l'équipe, il existe une grande variété de techniques antérieures dans ce domaine. Par exemple, three.js et Babylon JS sont des frameworks WebGL qui peuvent traiter de nombreux formats différents. Il y a aussi le projet model-viewer qui affiche des modèles en ligne dans une page Web et permet aussi aux utilisateurs de certains appareils de voir l'objet 3D en réalité augmentée. Enfin, iOS Safari permet de naviguer directement vers une vue en réalité augmentée grâce à sa [fonction AR Quick Look].
Cependant, ils notent qu'il existe des cas où ces options actuelles ne peuvent pas rendre le contenu. Cela peut être dû à des restrictions de sécurité ou aux limites de <canvas>. L'élément HTML <model> vise à permettre à un site Web d'intégrer des modèles 3D interactifs aussi facilement que tout autre média visuel. Les modèles sont censés être créés par des outils de création 3D ou générés dynamiquement, mais servis comme une ressource autonome par le serveur. Et, outre le simple affichage d'un modèle 3D, l'élément <model> devrait prendre en charge l'interactivité et les animations lorsqu'il est présenté dans la page.
L'équipe estime également qu'il devrait prendre en charge des expériences plus immersives, comme la réalité augmentée. « Cette proposition ne vise pas à définir un mécanisme permettant la création d'une scène 3D dans un navigateur à l'aide de primitives déclaratives ou d'une API programmatique », a-t-elle mis en garde.
HTMLModelElement : utilisation dans une page Web
L'élément <model> est un nouvel élément HTML remplacé similaire à <video> en ce sens qu'il est remplacé visuellement par le contenu d'une ressource externe référencée via un élément <source>. Comme les autres éléments HTML, il peut être stylé à l'aide de CSS. La ressource est résolue en sélectionnant les premiers éléments <source> avec un attribut de type supporté, ce qui permet de spécifier différentes versions de la même ressource dans différents formats. Voici un exemple montrant comment un fichier USDZ peut être affiché dans une zone mesurant 400px par 300px, avec un repli vers un fichier obj.
Code HTML : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Selon l'équipe, les navigateurs peuvent prendre en charge la manipulation directe de l'élément <model> lorsqu'il est présenté dans une page Web. Un navigateur peut permettre de faire pivoter ou de zoomer sur le modèle dans les limites de l'élément sans affecter la position de défilement ou le niveau de zoom de la page. Pour opter pour ce comportement, l'auteur peut utiliser l'attribut HTML interactif. L'exemple précédent peut être complété pour permettre interactive fournie par le navigateur. L'exemple précédent peut être complété pour permettre l'interaction fournie par le navigateur :
Code HTML : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
L'équipe a déclaré qu'il est également possible que les navigateurs prennent en charge une présentation animée du modèle, en exécutant des animations définies dans les données sources. Ces animations ne sont pas activées par défaut, mais peuvent être déclenchées au chargement en utilisant l'attribut HTML autoplay. L'exemple original peut être complété pour permettre de telles animations :
Code HTML : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
En outre, les attributs interactive et autoplay ne s'excluent pas mutuellement et peuvent être combinés. Un navigateur peut exécuter une animation par défaut qui est suspendue pendant que l'utilisateur interagit avec le modèle et qui est automatiquement reprise après une période d'inactivité. Ainsi, l'exemple original peut être complété pour permettre à la fois les animations et l'interactivité :
Code HTML : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Enfin, comme l'élément <video>, l'élément <model> possède un attribut poster facultatif qui référence une image à afficher pendant le chargement du contenu, ou si le contenu ne se charge pas.
L'élément HTMLModelElement et l'API DOM
Chaque élément <model> est représenté dans le DOM sous forme d'instances HTMLModelElement. Les propriétés suivantes permettent un accès facile aux informations autrement représentées par des attributs et des éléments HTML :
- currentSrc : chaîne en lecture seule renvoyant l'URL de la ressource chargée. Pour modifier la ressource chargée, l'auteur doit utiliser les API DOM existantes pour ajouter, supprimer ou modifier les éléments <source> enfants de l'élément <model> ;
- autoplay : booléen en lecture-écriture indiquant si le modèle lancera automatiquement la lecture. La définition de cette propriété à false supprime l'attribut HTML autoplay s'il est présent, tandis que sa définition à true ajoute l'attribut HTML autoplay s'il est absent ;
- interactive : booléen en lecture-écriture indiquant si le modèle est animé. La valeur false de cette propriété supprime l'attribut HTML interactive s'il est présent, tandis que la valeur true ajoute l'attribut HTML interactive s'il est absent.
Comme d'autres éléments avec des sous-ressources, l'élément HTMLModelElement fournira des API pour observer le chargement et le décodage des données. Par ailleurs, l'équipe a déclaré que bien que le HTML prenne en charge la notion de plein écran d'un élément, les navigateurs peuvent vouloir offrir des expériences encore plus immersives qui nécessitent d'aller au-delà de la page elle-même. Un exemple serait de présenter le modèle en réalité augmentée pour permettre à l'utilisateur de le visualiser à l'échelle réelle dans son environnement immédiat.
Pour cela, de nouvelles API DOM peuvent être ajoutées ou l'API HTML fullscreen existante peut être étendue grâce à des propriétés FullscreenOptions supplémentaires.
HTMLModelElement et les événements DOM
Bien que l'auteur puisse empêcher tout comportement interactif intégré pour un <model> en omettant l'attribut interactive, il pourrait être souhaitable que la décision d'autoriser un tel comportement interactif soit prise au moment de l'exécution. À cette fin, lorsqu'un utilisateur initie un geste sur un élément <model>, l'auteur peut appeler la méthode preventDefault() lors du traitement de l'événement pointer vers le bas.
Si cette méthode n'est pas appelée pour l'événement pointeur vers le bas pour le pointeur primaire d'un geste, l'appel de preventDefault() pour tout événement de pointeur supplémentaire n'aura aucun effet. Les événements de compatibilité mousedown et touchstart peuvent également être utilisés à cette fin.
Considérations relatives à la lecture et à l'accessibilité
Selon l'équipe, les ressources de modèle peuvent contenir de l'audio et des animations et, à ce titre, doivent être considérées comme d'autres médias et contenus animés par les navigateurs. Cela signifie que les comportements des navigateurs autour du chargement, de la lecture automatique et de l'accessibilité doivent être honorés pour l'élément <model> également, par exemple :
- une image statique de l'affiche peut être affichée avant le chargement de la ressource <model> complète ;
- le son peut être coupé jusqu'à ce que l'utilisateur interagisse avec l'élément <model> ;
- la lecture peut être désactivée si l'utilisateur a défini une préférence pour réduire les animations.
Comme d'autres médias temporisés, l'élément <model> fournira une API DOM pour la lecture, la mise en pause, la mise en sourdine, etc. L'élément <model> possède un attribut alt pour fournir une description textuelle du contenu. En outre, le contenu 3D lui-même pourrait exposer certaines caractéristiques au moteur d'accessibilité.
Considérations sur la confidentialité
Selon l'équipe, les données <model> rendues ne sont pas exposées à/extractibles par la page dans cette proposition, donc aucune altération n'est nécessaire. « Nous nous attendons à ce que cela nécessite des extensions de Fetch (un nouveau type de destination), de la politique de sécurité du contenu (une nouvelle directive de politique), et probablement quelques autres », a déclaré l'équipe.
Pourquoi ajouter un nouvel élément ?
« Nous pensons qu'il est temps que les fichiers représentant des données géométriques 3D deviennent des citoyens de première classe sur le Web », a déclaré l'équipe d'ingénieurs. L'ajout d'un nouvel élément à HTML nécessite une justification importante. À première vue, l'élément <model> ne semble pas nécessaire puisque HTML fournit déjà un mécanisme pour charger des données arbitraires et les rendre : <canvas et ses contextes de rendu. « Tout d'abord, nous pensons que ce type de contenu est suffisamment important pour ne pas nécessiter une bibliothèque tierce », explique-t-elle.
Selon elle, à l'instar des images matricielles, des images vectorielles, de l'audio et de la vidéo, les données géométriques tridimensionnelles devraient être un type de données qui peut être directement intégré dans le contenu HTML. « Deuxièmement, bien que nous ne proposions pas de DOM pour les données pour le moment, nous pensons le faire à l'avenir. Il serait avantageux pour le développeur Web d'apprendre une seule API commune pour la géométrie 3D plutôt que d'apprendre l'API de diverses bibliothèques tierces. En outre, les différents types de fichiers se conformeraient alors à la même API », poursuit-elle.
« Troisièmement, il existe des cas où une bibliothèque JavaScript ne peut pas rendre le contenu. Cela peut être dû à des restrictions de sécurité ou aux limites de <canvas>, qui est lié à une surface plane bidimensionnelle dans la page Web », a-t-elle ajouté. Prenons l'exemple d'un navigateur ou d'une vue Web affichée en réalité augmentée. Le développeur veut montrer un modèle 3D dans la page. Pour que le modèle soit précis, il doit être rendu du point de vue de l'utilisateur, sinon il s'agit d'un rendu plat d'une image tridimensionnelle avec une perspective incorrecte.
Une solution consisterait à permettre à la page Web, en particulier au WebGL qui affiche le modèle 3D, d'effectuer le rendu du point de vue de l'utilisateur. Cela impliquerait d'accorder trop d'informations privées à la page, y compris éventuellement le flux de la caméra, une certaine compréhension de la scène et des données très précises sur la position de l'utilisateur. Selon l'équipe, il ne devrait pas être nécessaire que chaque page Web doive demander la permission de montrer un modèle 3D de cette manière. L'utilisateur ne devrait pas avoir à donner accès à ces informations sensibles pour pouvoir profiter de cette expérience.
En outre, davantage d'informations sont nécessaires pour produire un rendu réaliste, comme la capacité de projeter et de recevoir des ombres et des réflexions d'autres contenus dans la scène, qui peuvent ne pas se trouver sur la même page Web. Cela signifie que le rendu en réalité augmentée est actuellement limité à un composant système, différent du composant dans la page, ce qui donne des résultats incohérents.
Les limites connues de l'élément <model>
Selon l'équipe, il n'est pas pratique de définir une approche de rendu précise au pixel près pour l'élément <model>. Si une telle tentative était faite, elle poserait probablement trop de restrictions aux moteurs de navigateurs, qui doivent fonctionner sur un certain nombre de systèmes d'exploitation, de matériels et d'environnements. L'équipe suggère plutôt d'adopter une approche de rendu basée sur la physique, en faisant probablement référence à un modèle d'ombrage existant tel que MaterialX.
Les navigateurs seraient libres d'implémenter le système comme ils le souhaitent, avec pour objectif de produire le rendu le plus précis possible. Toutefois, l'équipe a déclaré qu'elle ne s'attend pas à des résultats précis au pixel près entre les navigateurs. Et bien qu'il s'agisse d'un problème évident, l'équipe a ajouté que cela présente également de grands avantages, notamment :
- l'amélioration du matériel devrait se traduire par une amélioration de la qualité du rendu ;
- la qualité du contenu rendu peut s'améliorer sans nécessiter de modification de la source ;
- le navigateur peut utiliser l'environnement pour obtenir un affichage plus réaliste. Par exemple, les réflexions ou les ombres projetées par d'autres éléments de la scène de RA (une autre chose à laquelle il serait impossible pour le contenu de la page d'avoir accès).
Source : L'élément <model>
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
Répondre avec citation
Partager