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


183

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.


2
Vous ne voudrez peut-être pas mettre trop de stock dans un article HTML5 écrit il y a plus de 4,5 ans.
jessegavin

9
L'article de Crockford est étrange. La phrase importante est "Ceci est ma proposition pour un HTML 5 plus gentil et plus doux". En d'autres termes, ce n'est pas le HTML5 que nous connaissons aujourd'hui, mais une proposition d'un HTML 5 différent pour succéder à HTML 4. Bizarre, car il est daté de novembre 2007, alors que le W3C travaillait déjà sur HTML5 depuis près d'un an . Son utilisation du mot «autorisé» ici prête à confusion. Les balises personnalisées n'ont jamais été «conformes» / «valides», mais les analyseurs de navigateur continuent de fonctionner en leur présence. Quoi qu'il en soit, la proposition de Crockford n'a pas du tout gagné en popularité. Presque aucune partie de celui-ci n'est incorporée dans HTML5.
Alohci

3
Les éléments personnalisés deviennent de première classe maintenant que la nouvelle norme W3 pour les éléments personnalisés de composants Web commence à débarquer dans Firefox et Chrome: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/…
csuwldcat

3
Quant à Douglas Crockford, je suis tenté de croire tout ce qu'il dit.
wnrph

1
Tableau de support du navigateur Web pour les éléments personnalisés caniuse.com/#feat=custom-elements
Adrien Be

Réponses:


171

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


3
C'est une bonne réponse (+1) mais la règle est quelque peu circulaire. "Les utilisateurs ne doivent pas faire des choses qui ne sont pas autorisées ..."
Alohci

8
@Alohci vous devriez avoir ajouté les 3 mots suivants à votre citation: "par cette spécification".
jessegavin

1
J'ai aussi lu cette partie de la spécification, et cela m'a vraiment dérouté. Voici pourquoi: 1) les attributs personnalisés sont autorisés dans HTML5. Cela confirme l'observation de l'argument circulaire d'Alochi. 2) La spécification ne dit nulle part que les éléments personnalisés ne sont pas autorisés.
d13

Cette citation est au mieux vague. Le W3C a sûrement une position plus concrète dans un sens ou dans l'autre?
Flash

2
Ce lien vers customelements.io n'est plus utile. Pourriez-vous le mettre à jour / le supprimer?
Nisarg

22

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)


Il semble que vous n’avez pas lu toute cette section. Non seulement il s'agit principalement d' attributs , mais cela décourage même fortement la personnalisation.
Andrew Barber

En répétant mes autres commentaires, oui, je suis désolé de ne pas savoir indiquer que c'est mon blog. J'ai supposé que c'était évident. L'article est cependant directement pertinent. Et j'ajouterai que ce n'est pas censé servir de référence pour sauvegarder toute "revendication" que j'ai avancée, mais montrer dans un format plus long comment le faire pour que cela fonctionne.
svidgen

1
Le point est simplement ceci: la spécification autorise explicitement ces choses. Et dans la plupart des contextes de comportement décourageant , la spécification s'adresse assez clairement aux fournisseurs d'agents utilisateurs et non aux auteurs HTML.
svidgen

3
Cette déclaration citée ci-dessus semble avoir été supprimée dans la version la plus récente de w3.org/TR/html5/introduction.html#extensibility . Jusqu'à présent, je ne trouve toujours aucune documentation indiquant si l'utilisation d'éléments HTML personnalisés sans césure peut être valide ou non ou si vous avez besoin d'instructions JS pour valider les éléments HTML personnalisés avec césure ( html5rocks.com/en/tutorials/webcomponents/ éléments personnalisés ).
John Slegers

@JohnSlegers Oui, on dirait que la documentation et / ou l'ancrage a été un peu réorganisé. J'ai mis à jour le lien. La citation dans ma réponse est située près du bas de la section Extensibilité liée .
svidgen

14

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.


Ok, nous pouvons donc supposer que si les éléments personnalisés ne sont pas mentionnés, ils ne sont pas non plus autorisés. Cela semble assez juste.
d13

4
Cette réponse est désormais invalide, la nouvelle norme W3 Web Components Custom Elements commence à débarquer dans les navigateurs: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/…
csuwldcat

1
@csuwldcat - En fait, non. La norme HTML5 ou ultérieure devra encore être mise à jour d'une manière ou d'une autre pour permettre à ces éléments personnalisés de faire partie de son modèle de contenu. C'est une nouvelle intéressante cependant. Sur quels navigateurs puis-je les utiliser?
Alohci

3
@Alochi - de toute évidence, toutes les autres spécifications avec l'ancien langage devront être mises à jour pour refléter cette nouvelle réalité, mais le HTML est un niveau de vie et ne bloque pas les autres spécifications - les mises à jour seront effectuées une fois que nous passerons aux étapes suivantes de la norme Piste. Vous pouvez jouer avec les implémentations natives des composants Web dans Chrome Canary, et bientôt dans Firefox Aurora. De plus, il existe des polyfills disponibles pour 3 des 4 spécifications des composants Web qui fonctionnent très bien dans tous les navigateurs modeurs actuels - cela inclut les spécifications / fonctionnalités des éléments personnalisés.
csuwldcat

Des éléments personnalisés peuvent donc être placés à certains endroits? Ou dites-vous qu'ils ne sont pas du tout autorisés?
Melab

12

É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


11

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.


5

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.


1
Ce projet est-il adopté?
Starx

Certaines parties débarquent dans Firefox et Chrome - nous travaillons en étroite collaboration et prévoyons avoir des implémentations complètes d'ici la fin de 2013.
csuwldcat

1
Maintenant 2014, les implémentations complètes ont-elles atterri?
Hasib Mahmud

1
@JamieHutber et voyez vos pages Web se briser dans les derniers navigateurs dans un an. Règle n ° 1 pour l'interopérabilité des navigateurs: respectez les règles.
Mr Lister

1
@HasibMahmud les spécifications sont maintenant finalisées et arriveront sur Chrome Beta dans quelques semaines, Firefox Aurora dans ~ 6 semaines. Vous pouvez les utiliser dans Firefox Aurora aujourd'hui en basculant l'indicateur de configuration dom.webcomponents.enabledsur true.
csuwldcat

4

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.


3

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.


2

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


1

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! ;]


1
Il était valide pour le validateur car vous créiez ces éléments avec JavaScript, et le validateur ne les a pas vus car il n'exécute pas votre JavaScript. Il ne verrait que la page telle qu'elle apparaît lors du premier chargement.
animuson

Exactement. Bien que le HTML ne soit pas valide, les balises personnalisées sont toujours valides SGML et HTML est SGML après tout. CSS peut être utilisé pour styliser des balises personnalisées et fonctionne parfaitement dans IE. :) En outre, vous pouvez spécifier votre propre DTD avec vos propres éléments personnalisés dans votre spécification DOCTYPE, de sorte que mes balises personnalisées peuvent être validées même sans JavaScript - mais je m'en fiche - un système d'interface graphique de moteur de jeu n'est définitivement pas Google job :)
Петър Петров

1
Eh bien, il y a un hic. Vous ne pouvez pas simplement ajouter des éléments personnalisés bon gré mal gré. Vous devez les définir et les enregistrer avec la DTD pour qu'ils soient considérés comme du HTML "valide". Ce n'est pas parce que quelque chose fonctionne que c'est valable.
animuson

Si vous ajoutez simplement un qualificatif à vos noms d'élément, tel que <x-msg>, <x-log>, etc., vous seriez conforme à la spécification des composants Web / éléments personnalisés.
Neil Monroe le

Dans un moteur de jeu où Webkit n'est là que pour rendre votre interface graphique dynamique, personne ne se souciera également des DTD. Toute étiquette inconnue pour HTML est HTMLUnknownElement pour JS, travaille toujours parfaitement avec JQuery et CSS, de sorte que votre interface graphique obtient une sémantique à la fin: <inventory>, <item type="potion" sprite="2">- il est donc préférable d'être appelé CSS SGML + plutôt que HTML, malgré que les éléments HTML qui ont définition work as is - Boutons, listes, ...
Петър Петров

1

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.


1
Peut-être que cela arrivera quand ils arrêteront de soutenir <center>et <marquee>?
Ravenstine

1

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


3
C'est le HTML le plus étrange que j'ai vu ces derniers temps :)
Dan Dascalescu
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.