Les éléments personnalisés sont-ils compatibles HTML5?

J’ai été incapable de trouver une réponse définitive à la question de savoir si les balises personnalisées sont valides en HTML5, comme ceci:

Hello! 

Je n’ai rien trouvé dans la spécification d’une manière ou d’une autre:

http://dev.w3.org/html5/spec/single-page.html

Et les balises personnalisées ne semblent pas valider avec le validateur W3C.

La spécification des éléments personnalisés est disponible dans Chrome et Opera, et devient disponible dans d’ autres navigateurs . Il permet d’enregistrer de manière formelle des éléments personnalisés.

Les éléments personnalisés sont de nouveaux types d’éléments DOM pouvant être définis par les auteurs. Contrairement aux décorateurs , qui sont sans état et éphémères, les éléments personnalisés peuvent encapsuler l’état et fournir des interfaces de script.

Les éléments personnalisés font partie d’une plus grande spécification W3 appelée Web Components , avec les modèles, les importations HTML et les DOM Shadow.

Les composants Web permettent aux auteurs d’applications Web de définir des widgets avec un niveau de richesse visuelle et d’interactivité impossible avec CSS uniquement, et une facilité de composition et de réutilisation impossible avec les bibliothèques de scripts.

Cependant, à partir de cet excellent article sur les développeurs Google sur les éléments personnalisés v1:

Le nom d’un élément personnalisé doit contenir un tiret ( - ). Ainsi, , et sont tous des noms valides, tandis que et ne le sont pas. Cette exigence est telle que l’parsingur HTML puisse distinguer les éléments personnalisés des éléments normaux. Il garantit également la compatibilité avec les nouvelles balises lorsqu’elles sont ajoutées à HTML.

Quelques ressources

  • Une “galerie” de composants Web est en cours de compilation sur http://customelements.io/
  • WebComponents.js sert de polyfill pour les composants Web jusqu’à ce qu’ils soient pris en charge partout. Voir aussi la page WebComponents.js github et le tableau de support du navigateur Web .

C’est en réalité une conséquence de l’accumulation du modèle de contenu des éléments.

Par exemple, l’élément racine doit être un élément html .

L’élément html ne peut contenir qu’un élément head suivi d’un élément body.

L’élément body ne peut contenir que du contenu Flow où le contenu du stream est défini en tant qu’éléments: a, abbr, address, area (s’il s’agit d’un descendant d’un élément map), article, side, audio, bdi, bdo, blockquote, br, bouton, canvas, cite, code, commande, datalist, del, détails, dfn, div, em, embed, fieldset, figure, pied de page, formulaire, h1, h2, h3, h4, h5, en-tête, hgroup , hr, i, iframe, img, entrée, ins, kbd, keygen, étiquette, carte, marque, math, menu, compteur, nav, noscript, object, ol, sortie, p, pré, progrès, q, ruby, s , samp, script, section, select, small, span, strong, style (si l’atsortingbut scoped est présent), sub, sup, svg, table, textarea, time, u, ul, var, vidéo, wbr et texte

etc.

À aucun moment, le modèle de contenu ne dit “vous pouvez mettre des éléments que vous aimez dans celui-ci”, ce qui serait nécessaire pour les éléments / balises personnalisés.

C’est possible et permis:

Les agents utilisateurs doivent traiter les éléments et atsortingbuts qu’ils ne comprennent pas comme neutres sur le plan sémantique; en les laissant dans le DOM (pour les processeurs DOM) et en les stylisant selon CSS (pour les processeurs CSS), sans en déduire aucune signification.

http://www.w3.org/TR/html5/infrastructure.html#extensibility-0

Cependant, si vous souhaitez append de l’interactivité, vous devrez rendre votre document invalide (mais toujours pleinement fonctionnel) pour pouvoir accepter les éléments d’information 7 et 8 d’IE.

Voir http://blog.svidgen.com/2012/10/building-custom-xhtml5-tags.html (mon blog)

Éléments et atsortingbuts personnalisés de base

Les éléments et atsortingbuts personnalisés sont valides en HTML, à condition que:

  • Les noms d’élément sont minuscules et commencent par x-
  • Les noms d’atsortingbut sont en minuscule et commencent par data-

Par exemple, ou
.

Une convention commune pour les éléments est x-foo ; x-vendor-feature est recommandé.

Cela gère la plupart des cas, car il est rare qu’un développeur ait besoin de toute la puissance de l’enregistrement de ses éléments. La syntaxe est également valide et stable. Une explication plus détaillée est ci-dessous.

Éléments et atsortingbuts personnalisés avancés

En 2014, il existe une nouvelle méthode beaucoup plus efficace pour enregistrer des éléments et des atsortingbuts personnalisés. Cela ne fonctionnera pas dans les navigateurs plus anciens tels que IE 9 ou Chrome / Firefox 20. Mais cela vous permet d’utiliser l’interface standard HTMLElement , d’éviter les collisions, d’utiliser des noms non x-* et non- data-* et de définir un comportement personnalisé et la syntaxe à respecter par le navigateur. Il nécessite un peu de javascript, comme détaillé dans les liens ci-dessous.

HTML5 Rocks – Définir de nouveaux éléments en HTML
WebComponents.org – Introduction aux éléments personnalisés
W3C – Composants Web: éléments personnalisés

Concernant la validité de la syntaxe de base

L’utilisation de data-* pour les noms d’atsortingbuts personnalisés est parfaitement valide depuis un certain temps et fonctionne même avec les anciennes versions de HTML.

W3C – HTML5: Extensibilité

En ce qui concerne les noms d’éléments personnalisés (non enregistrés), le W3C les recommande fortement et les considère non conformes. Mais les navigateurs sont nécessaires pour les prendre en charge, et les identifiants x-* n’entreront pas en conflit avec les futures spécifications HTML et x-vendor-feature identificateurs de x-vendor-feature n’entreront pas en conflit avec d’autres développeurs. Une DTD personnalisée peut être utilisée pour contourner les navigateurs difficiles.

Voici quelques extraits pertinents des documents officiels:

“Les spécifications applicables PEUVENT définir un nouveau contenu de document (par exemple un élément foobar) […]. Si la syntaxe et la sémantique d’un document HTML5 conforme donné ne sont pas modifiées par l’utilisation des spécifications applicables, alors ce document rest un HTML5 conforme document.”

“Les agents utilisateurs doivent traiter les éléments et les atsortingbuts qu’ils ne comprennent pas comme neutres sur le plan sémantique; les laisser dans le DOM (pour les processeurs DOM) et les styliser selon CSS (pour les processeurs CSS), sans en déduire aucune signification.”

“Les agents utilisateurs ne sont pas libres de traiter les documents non conformes comme ils le souhaitent; le modèle de traitement décrit dans cette spécification s’applique aux implémentations indépendamment de la conformité des documents en entrée.”

“L’interface HTMLUnknownElement doit être utilisée pour les éléments HTML non définis par cette spécification.”

W3C – HTML5: documents conformes
WhatWG – HTML Standard: éléments DOM

Je voudrais souligner que le mot “valide” peut avoir deux significations différentes dans ce contexte, l’une ou l’autre étant potentiellement valide.

  1. Un document HTML avec des balises personnalisées doit-il être considéré comme valide HTML5? La réponse à cette question est clairement “non”. La spécification répertorie exactement quelles balises sont valides dans quels contextes. C’est pourquoi un validateur HTML n’acceptera pas un document avec des balises personnalisées ou avec des balises standard au mauvais endroit (comme une balise “img” dans l’en-tête).

  2. Un document HTML avec des balises personnalisées sera-t-il analysé et rendu de manière standard et clairement définie sur les navigateurs? Ici, peut-être étonnamment, la réponse est “oui”. Bien que le document ne soit pas techniquement considéré comme un HTML5 valide, la spécification HTML5 spécifie exactement ce que les navigateurs sont censés faire lorsqu’ils voient une balise personnalisée: en bref, la balise personnalisée agit comme un – cela ne veut rien dire et ne fait rien par défaut, mais il peut être stylé en HTML et accessible par javascript.

Les éléments HTML personnalisés sont une norme W3 émergente à laquelle j’ai consortingbué et qui vous permet de déclarer et d’enregistrer des éléments personnalisés avec l’parsingur. Vous pouvez lire les spécifications ici: Spécification des éléments Web de W3 Web Components . En outre, Microsoft prend en charge une bibliothèque (écrite par les anciens développeurs de Mozilla), appelée X-Tag , qui facilite encore plus le travail avec les composants Web.

Citant la section Extensibilité de la spécification HTML5 :

Pour les fonctionnalités de niveau balisage pouvant être limitées à la sérialisation XML et ne nécessitant pas de prise en charge dans la sérialisation HTML, les fournisseurs doivent utiliser le mécanisme d’espace de nommage pour définir des espaces de noms personnalisés dans lesquels les éléments et atsortingbuts non standard sont pris en charge.

Donc, si vous utilisez la sérialisation XML de HTML5, il est légal de faire quelque chose comme ceci:

 Hello! 

Cependant, si vous utilisez la syntaxe HTML, vous êtes beaucoup plus limité dans ce que vous pouvez faire.

Pour les fonctionnalités de niveau de balisage destinées à être utilisées avec la syntaxe HTML, les extensions doivent être limitées aux nouveaux atsortingbuts de la forme “x-vendor-feature” […] Les nouveaux noms d’élément ne doivent pas être créés.

Mais ces instructions s’adressent principalement aux fournisseurs de navigateurs, qui fourniraient vraisemblablement un style visuel et des fonctionnalités pour tous les éléments personnalisés qu’ils ont choisi de créer.

Pour un auteur, cependant, même s’il peut être légal d’incorporer un élément personnalisé dans la page (au moins dans la sérialisation XML), vous n’obtiendrez rien de plus qu’un nœud dans le DOM. Si vous voulez que votre élément personnalisé fasse quelque chose ou soit rendu d’une manière particulière, vous devriez regarder la spécification des éléments personnalisés .

Pour une introduction plus douce sur le sujet, lisez l’ Introduction aux composants Web , qui comprend également des informations sur le DOM Shadow et d’autres spécifications connexes. Ces spécifications sont toujours en cours d’élaboration – vous pouvez voir l’état actuel ici – mais elles sont activement développées.

Par exemple, une simple définition d’un élément de greeting pourrait ressembler à ceci:

    

Cela indique au navigateur de rendre le contenu de l’élément entre guillemets, et préfixé par le texte “Simon dit:” qui est stylé avec la couleur grise. En règle générale, une définition d’élément personnalisée comme celle-ci serait stockée dans un fichier HTML distinct que vous importeriez avec un lien.

  

Bien que vous puissiez également l’inclure en ligne si vous le souhaitez.

J’ai créé une démonstration fonctionnelle de la définition ci-dessus en utilisant la bibliothèque Polymer polyfill que vous pouvez voir ici . Notez que cela utilise une ancienne version de la bibliothèque Polymer – les versions plus récentes fonctionnent assez différemment. Cependant, avec les spécifications encore en développement, ce n’est pas quelque chose que je recommanderais d’utiliser dans le code de production de toute façon.

Pour donner une réponse actualisée reflétant les pages modernes.

Les balises personnalisées sont valides si l’une ou l’autre,

1) Ils contiennent un tiret

  

2) Ils sont XML incorporé

 Hello! 

Cela suppose que vous utilisez le doctype HTML5

Compte tenu de ces ressortingctions simples, il est maintenant logique de faire de votre mieux pour garder votre balise HTML valide (arrêtez de fermer les balises comme et


, sauf si vous utilisez un doctype XHTML, dont vous n’avez probablement pas besoin) ).

Étant donné que HTML5 définit clairement les règles d’parsing, un navigateur compatible sera en mesure de gérer n’importe quel tag que vous lui envoyez, même s’il n’est pas ssortingctement valide.

data-* atsortingbuts data-* sont valides en HTML5 et même en HTML4, tous les navigateurs Web les respectaient. L’ajout de nouvelles balises est techniquement correct, mais n’est pas recommandé simplement parce que:

  1. Cela peut entrer en conflit avec quelque chose ajouté à l’avenir, et
  2. Rend le document HTML invalide sauf s’il est ajouté dynamicment via JavaScript.

J’utilise des balises personnalisées uniquement dans les endroits où Google ne se soucie pas, par exemple dans un iframe de moteur de jeu, j’ai créé une contenant , et – mais uniquement via JavaScript . Et c’était tout à fait valide, selon le validateur. Il fonctionne même dans Internet Explorer avec son style! ;]

Les balises personnalisées ne sont pas valides en HTML5. Mais actuellement, les navigateurs prennent en charge leur parsing et vous pouvez également les utiliser avec css. Donc, si vous souhaitez utiliser des balises personnalisées pour les navigateurs actuels, vous pouvez le faire. Mais le support peut être supprimé une fois que les navigateurs ont mis en œuvre les normes W3C uniquement pour parsingr le contenu HTML.

Je sais que cette question est ancienne, mais j’ai étudié ce sujet et bien que certaines des affirmations ci-dessus soient correctes, elles ne sont pas le seul moyen de créer des éléments personnalisés. Par exemple:

   I won't be displayed :D    

fonctionnerait parfaitement bien (dans les nouvelles versions de Google Chrome, IE, FireFox et Safari mobile jusqu’à présent). Tout ce dont vous avez besoin est juste un caractère alpha (az, AZ) pour démarrer la balise, et vous pouvez ensuite utiliser n’importe quel caractère non alpha après. Si dans CSS, vous devez utiliser le “\” (barre oblique inverse) afin de trouver l’élément, comme cela nécessiterait une requête \ ^ {…}. Mais dans JS, vous l’appelez simplement comme vous le voyez. J’espère que ça aide. Voir exemple ici

-Mink CBOS