On peut créer et utiliser directement ses propres balises HTML

• En HTML, même si l’on utilise un nom de balise non reconnu, le navigateur le traite comme un élément générique
• En définissant ce nom de balise comme sélecteur en CSS, il est possible de le styliser et d’en contrôler l’affichage
• Utiliser un nom contenant un trait d’union (-) permet d’éviter les conflits avec les futurs standards HTML
• À la place de ou, employer des balises personnalisées porteuses de sens améliore la lisibilité du code
• Même dans des structures imbriquées complexes, le seul nom des balises suffit à comprendre la structure, ce qui facilite la maintenance

---

Utilisation des balises HTML personnalisées

• Le navigateur affiche les balises inconnues comme des éléments de bloc génériques

  • Il s’agit d’un comportement normal défini par le standard HTML, et leur apparence peut être contrôlée visuellement via du CSS
  • Par exemple, on peut définir une balise comme `` et la styliser en CSS avec cool-thing { ... }

• Si le nom de balise contient un trait d’union (-), il n’y a aucun risque de conflit avec un futur ajout au standard HTML

  • Ex. : ,

Lisibilité et amélioration de la structure

• Utiliser des balises aux noms explicites à la place de ou rend le code plus facile à comprendre
  • Par exemple, on peut utiliser au lieu de
• Dans une structure imbriquée de ``, il est difficile de repérer à quelle balise correspond une fermeture, mais des noms de balises explicites rendent la structure plus claire
  • Si contient, ``, etc., la structure du DOM devient intuitive à lire

Exemple de code

• Méthode classique

  
    Hello, World!
  
  

• Avec des balises personnalisées

  
    Hello, World!
  
  

  • En CSS, on peut appliquer des styles comme cool-thing { display: block; font-weight: bold; text-align: center; ... }

Conclusion

• En exploitant la souplesse de définition des balises autorisée par le standard HTML, il est possible d’écrire un markup structurel plus lisible
• Toutefois, lorsqu’une balise sémantique existante convient déjà, il faut la privilégier

[GN⁺]

Avis sur Hacker News

• Souligne que n’est pas une balise non reconnue Il présente son [article de blog](https://dashed-html.github.io), expliquant que est traité comme un HTMLUnknownElement jusqu’à ce que le WHATWG l’ajoute comme nouvel élément, tandis que est un **HTMLElement valide**, utile pour la mise en page et le style Si on le met à niveau via la JavaScript Custom Elements API, il devient un **custom element défini** C’est un comportement standard dans tous les navigateurs, et le validateur HTML du W3C reconnaît aussi les custom elements avec tiret comme des HTMLElement En revanche, la règle `[hidden]{display:none}` de la feuille de style UA par défaut n’est pas héritée, donc il faut la définir soi-même Comme le fait que ait par défaut display:block vient aussi de la feuille de style UA, il faut définir explicitement la propriété display pour les custom elements Les sélecteurs CSS :defined et :not(:defined) permettent de distinguer les éléments définis et non définis Le Declarative Shadow DOM (``) crée lui aussi des custom elements non définis

  • Réplique qu’avec Chromium, ce n’est pas un problème de feuille de style UA, mais du fait que hidden est un attribut de présentation HTML La feuille de style UA s’applique de la même manière aux custom elements, et il n’existe pas de règle [hidden] hidden est un exemple où l’attribut lui-même est interprété comme du style, comme align="right"
  • Regrette qu’on n’ait pas pu utiliser un deux-points (:) au lieu d’un tiret (-), ce qui aurait permis d’intégrer naturellement les espaces de noms XML Il mentionne aussi qu’il aurait été possible, dans nginx ou apache, de convertir les deux-points en tirets Il conclut sur une note nostalgique, disant qu’« on ne peut pas retourner en 1999 »
  • S’interroge sur le fait que cette approche ne soit pas la pratique par défaut

• Fait remarquer que la structure imbriquée en dans l’exemple est excessive Il propose d’utiliser plutôt des **balises sémantiques** comme, et

  • Souligne que, contrairement à un attribut de classe, une balise custom ne peut avoir qu’un seul nom Une classe peut en avoir plusieurs et n’a pas d’ordre, tandis que des custom elements imbriqués imposent un ordre, ce qui rend la même expressivité plus difficile
  • Analyse que le problème n’est pas le « div soup » en soi, mais le résultat d’une décision de conception de HTML qui lie fortement structure et style C’était pertinent en 1996, mais ne l’est plus aujourd’hui selon lui

• Partage son expérience de 3 à 4 ans d’utilisation des custom elements L’idée est maligne, mais délicate en pratique Trop de balises custom nuisent à la lisibilité et rendent la distinction bloc/en ligne difficile Avec une approche équilibrée, il conserve les balises de base et n’utilise des custom tags que pour des éléments de type composant comme ou Les sous-composants sont distingués via un attribut slot, comme dans `` Il préfère réserver les classes à la modification et à la personnalisation, et exprimer la structure via les slots

  • Dit s’intéresser beaucoup à une approche équilibrée des Web Components et demande des exemples ou une boîte à outils Il présente Good.HTML, qu’il a créé, en expliquant qu’il prend en charge les hooks automatiques (autohook), l’interpolation basée sur les template literals et une structure de composants ordonnée Il ajoute avoir implémenté aussi des custom elements auto-fermants comme < !app-header /> avec une astuce basée sur des nœuds de commentaire
  • Demande si, pour sélectionner par attribut slot en CSS, il faut écrire div[slot="hero-blurb"]
  • Mentionne que ce motif lui rappelle la structure block–element de BEM

• Les custom tags se comportent essentiellement comme `` Si nécessaire, on peut définir leur comportement via la Custom Element API

  • Dit avoir largement utilisé les custom elements en 2014 et exprime son regret que React se soit imposé Il pense que, pour la plupart des utilisateurs, une combinaison HTML + custom elements aurait été préférable à une SPA
  • Estime qu’il vaut mieux privilégier d’abord les éléments sémantiques, puis n’utiliser des custom elements qu’en cas de besoin Il partage un exemple de Hypalink qu’il a créé et souligne la sous-estimation des Web Components

• Présente un custom tag nommé qui joue le rôle inverse de Il peut masquer une zone spécifique lorsque JS est désactivé Il partage le lien du projet

  • Propose qu’on peut obtenir le même effet uniquement en CSS grâce à @media (scripting) Il ajoute un lien vers la documentation MDN

• Partage une expérience où il a recréé lui-même l’ancienne balise ``, retirée des navigateurs Il l’a implémentée avec jQuery et en manipulant visibility, et dit avoir été surpris que les navigateurs autorisent des balises arbitraires Le code faisait une dizaine de lignes, donc il ne l’a pas publié, mais suppose qu’il existe beaucoup d’essais similaires

  • Explique qu’en réalité, la plupart des navigateurs n’ont jamais implémenté ``, et que seuls Firefox et Opera l’ont supportée jusqu’en 2013
  • Dit regretter encore la disparition de Flash
  • Affirme qu’on peut aussi reproduire l’effet `` uniquement en CSS et partage un exemple de code Il précise qu’en utilisant le sélecteur blink au lieu de .blink, l’effet s’applique directement à la balise
  • Déclare qu’un comportement comme `` a une portée trop importante pour être fourni comme simple élément HTML, et se réjouit donc de sa disparition

• Fait remarquer que des exemples comme ou peuvent être remplacés par de vraies balises HTML Il est plus approprié d’utiliser , et ``

  • Ajoute qu’en utilisant des balises HTML prédéfinies, on bénéficie aussi du style par défaut du navigateur

• Les custom tags sont rendus en ligne par défaut, comme ``, mais il suffit de définir une propriété display par défaut en CSS Autrefois, on les évitait à cause des problèmes d’espaces de noms, mais l’autorisation du tiret (-) dans le standard a supprimé le risque de collision Ils fonctionnent aussi sans problème dans les sélecteurs CSS, et sont accessibles via querySelector Il estime que le HTML moderne suffit déjà à être expressif, même sans framework comme Vue

  • Précise que les éléments non standards contenant un tiret sont traités comme des HTMLElement et non des HTMLUnknownElement Cela a été conçu pour que, lors d’une future mise à niveau, la chaîne de prototypes puisse être étendue naturellement

• Pour définir un style par défaut à tous les custom elements, on peut faire ainsi

  :where(:not(:defined)) {
    display: block;
  }
  

  • Dit qu’il cherchait justement cette méthode, et exprime sa surprise admirative et sa gratitude

• Se souvient qu’à l’époque, IE ne reconnaissait pas les balises HTML5, et qu’il avait résolu cela vers 2010 avec un script qu’il avait écrit Il suffisait de créer une balise une fois en JS pour qu’IE la reconnaisse, et il n’y avait ensuite aucun problème même après sa suppression Il dit avoir compris grâce à cela qu’il était aussi possible de rendre des balises arbitraires Il partage aussi son article de blog de l’époque

  • Ajoute que le populaire html5shim fonctionnait de la même manière