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

Je n'ai pas pu trouver de réponse définitive pour savoir si les balises personnalisées sont valides en HTML5, comme ceci:

<greeting>Hello!</greeting>

Je n'ai rien trouvé dans la spécification dans un sens ou dans l'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 fournit un moyen d'enregistrer des éléments personnalisés de manière formelle.

Les éléments personnalisés sont de nouveaux types d'éléments DOM qui peuvent ê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 spécification W3 plus large appelée Composants Web , avec les modèles, les importations HTML et Shadow DOM.

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 seul, et une facilité de composition et de réutilisation impossible avec les bibliothèques de scripts aujourd'hui.

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 ( -). Donc <x-tags>, <my-element>et <my-awesome-app>sont tous des noms valides, tandis que <tabs>et <foo_bar>ne le sont pas. Cette exigence est que l'analyseur HTML puisse distinguer les éléments personnalisés des éléments réguliers. Il garantit également la compatibilité ascendante lorsque de nouvelles balises sont ajoutées au HTML.

Quelques ressources

• Des exemples de composants Web sont disponibles sur https://WebComponents.org
• WebComponents.js sert de polyfill pour les composants Web jusqu'à ce qu'ils soient pris en charge partout. Voir également la page github WebComponents.js et le tableau de prise en charge du navigateur Web .

C'est possible et permis:

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

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

Mais, si vous avez l'intention d'ajouter de l'interactivité, vous devrez rendre votre document invalide (mais toujours pleinement fonctionnel) pour accueillir les 7 et 8 d'IE.

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

NB La réponse ci-dessous était correcte lors de sa rédaction en 2012. Depuis, les choses ont un peu évolué. La spécification HTML définit maintenant deux types d'éléments personnalisés - «éléments personnalisés autonomes» et «éléments intégrés personnalisés». Le premier peut aller partout où le contenu de phrasé est attendu; qui est la plupart des endroits à l'intérieur du corps, mais pas par exemple les enfants d'éléments ul ou ol, ou dans des éléments de tableau autres que les éléments td, th ou caption. Ces derniers peuvent aller partout où l'élément qu'ils prolongent peut aller.

C'est en fait une conséquence de l'accumulation du modèle de contenu des éléments.

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

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

L' bodyélément ne peut contenir que du contenu Flow où le contenu Flow est défini comme les éléments: a, abbr, adresse, zone (s'il s'agit d'un descendant d'un élément de carte), article, aparté, audio, b, bdi, bdo, blockquote, br, bouton, canevas, cite, code, commande, datalist, del, détails , dfn, div dl, em, incorporer, fieldset, figure, pied de page, formulaire, h1, h2, h3, h4, h5, h6, en-tête, hgroup, hr, i, iframe, img, entrée, ins, kbd, keygen, étiquette, carte, marque, math, menu, mètre, nav, noscript, objet, ol, sortie, p, pré, progression, q, ruby, s, samp, script, section, sélectionnez, petit, span, fort, style ( si l'attribut de portée est présent), sub, sup, svg, table, textarea, time,u, ul, var, video, wbr et texte

etc.

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

Éléments et attributs personnalisés de base

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

• Les noms des éléments sont en minuscules et commencent par x-
• Les noms d'attributs sont en minuscules et commencent par data-

Par exemple, <x-foo data-bar="gaz"/>ou <br data-bar="gaz"/>.

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

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

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

Depuis 2014, il existe un nouveau moyen bien amélioré d'enregistrer des éléments et des attributs 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' HTMLElementinterface standard , d'éviter les collisions, d'utiliser des non x-*- data-*noms et des non- noms, et de définir un comportement et une syntaxe personnalisés que le navigateur doit respecter . Cela nécessite un peu de JavaScript sophistiqué, comme détaillé dans les liens ci-dessous.

HTML5 Rocks - Définition 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 data-*des noms d'attributs 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ément personnalisés (non enregistrés), le W3C les déconseille vivement et les considère non conformes. Mais les navigateurs sont tenus de les prendre en charge et les x-*identifiants ne seront pas en conflit avec les futures spécifications HTML et les x-vendor-featureidentifiants ne seront pas en conflit avec d'autres développeurs. Une DTD personnalisée peut être utilisée pour contourner tous les navigateurs difficiles.

Voici quelques extraits pertinents de la documentation officielle:

"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é restent inchangées par l'utilisation de la ou des spécifications applicables, alors ce document reste un HTML5 conforme document."

"Les agents utilisateurs doivent traiter les éléments et attributs qu'ils ne comprennent pas comme sémantiquement neutres; les laisser dans le DOM (pour les processeurs DOM), et les styliser selon CSS (pour les processeurs CSS), mais sans en déduire aucune signification."

"Les agents utilisateurs ne sont pas libres de traiter les documents non conformes à leur guise; le modèle de traitement décrit dans cette spécification s'applique aux implémentations indépendamment de la conformité des documents d'entrée."

"L'interface HTMLUnknownElement doit être utilisée pour les éléments HTML qui ne sont pas définis par cette spécification."

W3C - HTML5: documents conformes
WhatWG - Norme HTML: éléments DOM

Je tiens à souligner que le mot "valide" peut avoir deux sens différents dans ce contexte, l'un ou l'autre étant potentiellement, euh, valide.

1. Un document HTML avec des balises personnalisées doit-il être considéré comme du HTML5 valide? La réponse à cela 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 aux mauvais endroits (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 dans les navigateurs? Ici, peut-être étonnamment, la réponse est «oui». Même si le document ne serait pas techniquement considéré comme du 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 un peu comme un <span>- cela ne signifie rien et ne fait rien en par défaut, mais il peut être stylisé par HTML et accessible par javascript.

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

Pour donner une réponse mise à jour reflétant les pages modernes.

Les balises personnalisées sont valides si l'un ou l'autre,

1) Ils contiennent un tiret

<my-element>

2) Ils sont du XML intégré

<greeting xmlns="http://example.com/customNamespace">Hello!</greeting>

Cela suppose que vous utilisez le doctype HTML5 <!doctype html>

Compte tenu de ces restrictions simples, il est maintenant logique de faire de votre mieux pour garder votre balisage HTML valide (veuillez arrêter de fermer les balises comme <img>et <hr>, c'est idiot et incorrect à moins que vous n'utilisiez un doctype XHTML, dont vous n'avez probablement pas besoin).

Étant donné que HTML5 définit clairement les règles d'analyse, un navigateur conforme sera capable de gérer n'importe quelle balise que vous lui lancez même si elle n'est pas strictement valide.

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

Pour les fonctionnalités au niveau du balisage qui peuvent être limitées à la sérialisation XML et qui n'ont pas besoin d'être prises en charge dans la sérialisation HTML, les fournisseurs doivent utiliser le mécanisme d'espace de noms pour définir des espaces de noms personnalisés dans lesquels les éléments et attributs non standard sont pris en charge.

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

<greeting xmlns="http://example.com/customNamespace">Hello!</greeting>

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

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

Mais ces instructions sont principalement destinées aux fournisseurs de navigateurs, qui fourniraient supposément un style visuel et des fonctionnalités pour les éléments personnalisés qu'ils choisiraient 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 réellement quelque chose ou soit rendu d'une manière spéciale, vous devriez regarder la spécification des éléments personnalisés .

Pour une introduction plus douce sur le sujet, lisez l' introduction des composants Web , qui comprend également des informations sur Shadow DOM et d'autres spécifications associées. Ces spécifications sont encore en cours de rédaction pour le moment - vous pouvez voir l'état actuel ici - mais elles sont activement développées.

À titre d'exemple, une définition simple d'un greetingélément peut ressembler à ceci:

<element name="greeting">
  <template>
    <style scoped>
      span { color:gray; }
    </style>
    <span>Simon says:</span>
    <q><content/></q>
  </template>
</element>

Cela indique au navigateur de rendre le contenu de l'élément entre guillemets, et préfixé par le texte "Simon dit:" qui est de style gris. 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.

<link rel="import" href="greeting-definition.html" />

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

J'ai créé une démonstration de travail 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 la spécification toujours en développement, ce n'est pas quelque chose que je recommanderais de toute façon d'utiliser dans le code de production.

utilisez simplement ce que vous voulez sans aucune déclaration dom

<container>content here</container>

ajoutez votre propre style (affichage: bloc) et cela fonctionnera avec n'importe quel navigateur moderne

data-*les attributs sont valides en HTML5 et même en HTML4, tous les navigateurs Web utilisés pour les respecter. L'ajout de nouvelles balises est techniquement acceptable, mais n'est pas recommandé simplement parce que:

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

J'utilise des balises personnalisées uniquement dans des endroits que Google ne se soucie pas, par exemple dans un iframe de moteur de jeu, j'ai créé une <log>balise qui contenait <msg>, <error>et <warning>- mais via JavaScript uniquement. Et c'était pleinement valable, 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 analyse et vous pouvez également les utiliser en utilisant css. Donc, si vous souhaitez utiliser des balises personnalisées pour les navigateurs actuels, vous le pouvez. Mais le support peut être supprimé une fois que les navigateurs implémentent les normes W3C strictement pour l'analyse du contenu HTML.

Je sais que cette question est ancienne, mais j'ai étudié ce sujet et bien que certaines des déclarations ci-dessus soient correctes, elles ne sont pas la seule façon de créer des éléments personnalisés. Par exemple:

<button id="find">click me</button>
<Query? ?attach="find" ?content="alert( find() );" ?prov="Hello there :D" >
I won't be displayed :D
</Query?>

<style type="text/css">

[\?content] {

display: none;

}

</style>

<script type="text/javascript">

S = document.getElementsByTagName("Query?")[0];

Q = S.getAttribute("?content");

A = document.getElementById( S.getAttribute("?attach") );

function find() {

  return S.getAttribute("?prov");

}

(function() {

A.setAttribute("onclick", Q);

})();

</script>

fonctionnerait parfaitement bien (dans les versions plus récentes 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, puis vous pouvez utiliser l'un des caractères non alpha après. Si en CSS, vous devez utiliser le "\" (barre oblique inverse) pour trouver l'élément, comme cela aurait besoin de Query \ ^ {...}. Mais dans JS, vous l'appelez simplement comme vous le voyez. J'espère que cela aide. Voir l'exemple ici

-Mink CBOS