Résumé

  • Le W3C publie le premier projet public Custom Elements le 14 mai 2013. Un projet de 2016 détaille les classes, le registre, l’activation d’éléments présents et les rappels de cycle de vie ; une note de 2018 décrit le transfert de ces règles vers DOM et HTML.
  • Dans le standard HTML actuel, un auteur enregistre sa définition auprès d’un CustomElementRegistry. Le navigateur associe les balises admissibles et déclenche leurs réactions lors de la connexion, du départ ou d’un changement d’attribut suivi.

Une rédaction veut une carte qui rassemble titre, photo et lien de lecture. Elle pourrait chercher toutes les cartes après chaque chargement et appeler à la main le script qui les prépare. Mais la carte pourrait aussi porter son métier avec elle : le navigateur reconnaît son nom, active la définition et signale quand elle entre ou sort de la page. La seconde méthode transforme une suite de recherches dispersées en contrat attaché à l’élément.

Le premier projet public du W3C, daté du 14 mai 2013, formulait l’idée d’autoriser les auteurs à définir de nouveaux types d’éléments DOM. Son modèle associait un nom, un prototype et des rappels de cycle de vie. Les détails ont changé depuis, mais la répartition était déjà là : le navigateur gère l’existence du type dans le document, l’auteur décide de son comportement.

Le projet du W3C du 9 juin 2016 ressemble davantage au bureau actuel. L’auteur crée une classe dérivée de HTMLElement et la déclare avec customElements.define(). Un exemple du projet place une balise dans le document avant que sa définition soit enregistrée. Une fois celle-ci arrivée, l’élément admissible est activé. La page peut donc avoir préparé le poste avant l’arrivée de la personne qui sait l’occuper.

Le registre vérifie les noms et organise activation et réactions. Le trait d’union dans le nom d’un élément autonome aide à réserver cette zone aux balises définies par des auteurs. Une liste d’attributs observés indique ceux dont les changements intéressent la carte. attributeChangedCallback() traite ces modifications ; connectedCallback() accompagne l’entrée dans le document ; disconnectedCallback() accompagne la sortie. Le navigateur règle l’appel de ces méthodes selon les règles de réaction des éléments personnalisés.

Une telle balise a une vraie vie. Elle peut être présente avant le chargement du script, être activée plus tard, puis être déplacée ou retirée. Son auteur doit écrire un code capable de vivre ces étapes, y compris plusieurs connexions. Le navigateur tient le registre et le calendrier ; il ne choisit ni la photo, ni le titre, ni le bon dessin de la carte. Une fiche de poste ne remplace pas le métier.

Le document autonome a ensuite changé d’adresse. La note du groupe de travail du 3 mai 2018 indique que la matière de Custom Elements était incorporée aux spécifications DOM, HTML et à d’autres textes pertinents. L’historique de publication du W3C garde la trace du projet initial de 2013, des projets ultérieurs et de la transition de 2018. Le mécanisme a rejoint les règles générales de la plateforme.

Le chapitre Custom Elements du standard HTML vivant de WHATWG expose aujourd’hui le registre, les vérifications de noms, l’activation et les files de réactions. Il couvre aussi des situations développées plus tard, comme l’adoption ou la participation aux formulaires. Le principe central tient dans une décision de chacun : le navigateur rattache un nom reconnu à une définition et appelle les réactions ; l’auteur donne à la balise son comportement utile.

Shadow DOM règle la composition d’un arbre interne et ses points de contact avec la page. Custom Elements règle l’identité et la carrière de la balise. Les deux peuvent travailler ensemble. Pour notre carte de récit, le premier dessine éventuellement son atelier ; le second lui donne un badge et lui dit quand commencer sa journée.