Quels sont tous les éléments valides à fermeture automatique en XHTML (tels qu'implémentés par les principaux navigateurs)?

188

Quels sont tous les éléments valides à fermeture automatique (par exemple <br/>) en XHTML (tels qu'implémentés par les principaux navigateurs)?

Je sais que XHTML permet techniquement à n'importe quel élément d'être auto-fermé, mais je recherche une liste de ces éléments pris en charge par tous les principaux navigateurs. Voir http://dusan.fora.si/blog/self-closing-tags pour des exemples de certains problèmes causés par des éléments à fermeture automatique tels que <div />.

les kamens
la source
7
N'est-ce pas par défaut l'un des objectifs de XHTML? Je pensais que l'un des avantages du XHTML était que vous pouviez utiliser un générateur XML pour générer du HTML. Pourquoi un générateur XML sait-il quelles balises sont autorisées à se fermer automatiquement? Trop bizarre.
Elijah
6
La raison pour laquelle la réponse «boiteuse», «incorrecte» a été acceptée est qu'elle répondait à la question que les kamens posaient manifestement. Il voulait savoir quels éléments pouvaient être auto-fermés lors de la diffusion de XHTML sous forme de texte / html sans causer de problèmes de rendu dans les navigateurs. De nombreuses pages sont écrites en XHTML et servies sous forme de texte / html, même si elles sont techniquement incorrectes. La question pourrait être améliorée avec cette clarification, mais répondre à une question différente (que se passe-t-il lorsque vous servez en tant qu'application / xml, ou si les balises singulières dans text / html doivent avoir une fermeture /) n'est pas utile dans ce cas.
Nick Lockwood du

Réponses:

180

Chaque navigateur prenant en charge XHTML (Firefox, Opera, Safari, IE9 ) prend en charge la syntaxe de fermeture automatique sur chaque élément .

<div/>, <script/>, <br></br>Tout devrait fonctionner très bien. Si ce n'est pas le cas, vous avez du HTML avec du DOCTYPE XHTML ajouté de manière inappropriée.

DOCTYPE ne change pas la façon dont le document est interprété. Seul le type MIME le fait .

Décision du W3C d'ignorer DOCTYPE :

Le GT HTML a discuté de ce problème: l'intention était d'autoriser les anciens navigateurs (HTML uniquement) à accepter les documents XHTML 1.0 en suivant les instructions et en les servant en texte / html. Par conséquent, les documents servis sous forme de texte / html doivent être traités comme du HTML et non comme du XHTML.

C'est un piège très courant, car W3C Validator ignore largement cette règle, mais les navigateurs la suivent religieusement. Lisez Comprendre HTML, XML et XHTML sur le blog WebKit:

En fait, la grande majorité des documents supposés XHTML sur Internet sont servis sous forme de fichiers text/html. Ce qui signifie qu'ils ne sont pas du tout du XHTML, mais en fait du HTML invalide qui se débrouille avec la gestion des erreurs des analyseurs HTML. Tous ces "Valid XHTML 1.0!" les liens sur le Web indiquent vraiment «HTML 4.01 invalide!».


Pour tester si vous avez du vrai XHTML ou du HTML invalide avec le DOCTYPE de XHTML, mettez ceci dans votre document:

<span style="color:green"><span style="color:red"/> 
 If it's red, it's HTML. Green is XHTML.
</span>

Il valide, et en vrai XHTML cela fonctionne parfaitement (voir: 1 vs 2 ). Si vous n'en croyez pas vos yeux (ou ne savez pas comment définir les types MIME), ouvrez votre page via le proxy XHTML .

Une autre façon de vérifier est de voir la source dans Firefox. Il mettra en évidence les barres obliques en rouge lorsqu'elles sont invalides.

En HTML5 / XHTML5, cela n'a pas changé et la distinction est encore plus claire, car vous n'en avez même pas d'autres DOCTYPE. Content-Typeest le roi.


Pour mémoire, la spécification XHTML permet à tout élément de se fermer automatiquement en faisant de XHTML une application XML : [c'est moi qui souligne]

Les balises d'élément vide peuvent être utilisées pour tout élément qui n'a pas de contenu , qu'il soit déclaré ou non à l'aide du mot-clé EMPTY.

Il est également explicitement indiqué dans la spécification XHTML :

Les éléments vides doivent soit avoir une balise de fin ou la balise de début doit se terminer par />. Par exemple, <br/>ou<hr></hr>

Kornel
la source
7
Afaik incorrect, car l'utilisation de versions à fermeture automatique de <script>ou <div>entraîne un rendu / interprétation différent.
ZeissS
13
@ZeissS uniquement dans text/html. En vrai XHTML, envoyé car application/xhtml+xmlil fonctionne très bien. Veuillez lire l'article auquel j'ai lié (ou l'annexe C des spécifications XHTML) avant de voter.
Kornel
3
@pornel pouvez-vous garantir que les balises à fermeture automatique <script /> fonctionneront dans les anciens navigateurs? Je ne pense pas. Vous semblez faire autorité, et la plupart de vos informations sont exactes, mais l'expérience me dit que les balises de script à fermeture automatique seront problématiques et qu'il vaut mieux les éviter complètement plutôt que de vous donner mal à la tête.
Metagrapher
6
@Metagrapher si les anciens navigateurs ne prennent pas en charge le vrai XHTML, OU si vous ne parvenez pas à définir le type MIME , cela ne fonctionnera pas. Cependant, dans les navigateurs prenant en charge XHTML (tous les principaux à ce stade) avec le application/xhtml+xmltype MIME, je peux garantir que <script/>cela fonctionnera. Avec le type MIME. Seulement.
Kornel
4
@capdragon: les navigateurs plus anciens ne prennent pas en charge XHTML (servi comme 'application / xhtml + xml'). Si vous leur envoyez un document XHTML en tant que 'text / html', alors le XHTML est rendu sous forme de soupe de balises (c'est-à-dire que le navigateur l'analyse en HTML et considère les erreurs de balises à fermeture automatique, dont il récupère gracieusement). Vos options sont 1. écrivez HTML 4 (pas exactement une option si vous utilisez ASP.NET qui rend XHTML), 2. servez votre XHTML comme 'application / xhtml + xml' (nécessite IE9 +, et ce type MIME cassera les scripts dans tous les navigateurs de toute façon, donc ce n'est pas une option), 3. écrivez HTML 5, ce qui fait de la soupe aux balises la norme :)
Triynko
41

Un élément avec lequel il faut être très prudent sur ce sujet est l' <scriptélément>. Si vous avez un fichier source externe, cela causera des problèmes lorsque vous le fermerez vous-même. Essayez-le:

<!-- this will not consistently work in all browsers! -->
<script type="text/javascript" src="external.js" />

Cela fonctionnera dans Firefox, mais casse au moins dans IE6. Je sais, parce que je suis tombé sur ça quand j'ai fermé avec zèle chaque élément que j'ai vu ;-)

Erik van Brakel
la source
Affecte toutes les versions de MSIE: webbugtrack.blogspot.com/2007/08/…
scunliffe
4
<script> ne se ferme pas automatiquement dans Firefox 3.
hsivonen
Eh bien, cela fonctionnait dans Firefox quand je l'ai rencontré. On dirait que cela ne fonctionne plus dans aucun navigateur. Peut-être aussi fonctionner uniquement en mode bizarreries?
Erik van Brakel
1
@erickson cela fonctionne bien dans Firefox si vous obtenez votre type MIME correctement.
Kornel
WebKit continue de le faire pour des raisons de compatibilité.
Yuhong Bao
35

La syntaxe à fermeture automatique fonctionne sur tous les éléments de application / xhtml + xml. Il n'est pris en charge sur aucun élément de texte / html, mais les éléments qui sont «vides» en HTML4 ou «void» en HTML5 ne prennent de toute façon pas de balise de fin, donc si vous mettez une barre oblique sur ceux-ci, il apparaît comme si la syntaxe à fermeture automatique était prise en charge.

hsivonen
la source
33

Depuis le site de référence des écoles W3 :

<area />
<base />
<basefont />
<br />
<hr />
<input />
<img />
<link />
<meta />
ConroyP
la source
7
w3schools.com/tags/default.asp Je vois 12 balises se terminant par />:"area", "base", "basefont", "br", "col", "frame", "hr", "img", "input", "link", "meta", "param"
mpen
94
Veuillez noter que W3schools n'est pas affilié au W3C et ne répond même pas aux corrections envoyées par les membres du W3C.
Kornel
2
Comme souvent, w3schools a presque raison. Un moyen précis de trouver les éléments vides est d'exécuter grep EMPTY xhtml1-strict.dtd | sortougrep EMPTY xhtml1-transitional.dtd | sort
cayhorstmann
1
IMHO, les gens critiquent W3Schools beaucoup trop dur. Il s'est avéré être une excellente ressource pour vous lancer (!) Sur un sujet dont vous ne savez rien.
Priidu Neemre
28

La meilleure question serait: quelles balises peuvent être auto-fermées même en mode HTML sans affecter le code? Réponse: seuls ceux qui ont un contenu vide (sont nuls). Selon les spécifications HTML, les éléments suivants sont nuls:

area, base, br, col, embed, hr, img, input, keygen, link, menuitem, meta, param, source, track, wbr

Ancienne version de la spécification également répertoriée command. En outre, selon diverses sources, les balises obsolètes ou non standard suivantes sont nulles:

basefont, bgsound, frame, isindex

Dmitry Osinovskiy
la source
10

J'espère que cela aide quelqu'un:

<base />
<basefont />
<frame />
<link />
<meta />

<area />
<br />
<col />
<hr />
<img />
<input />
<param />
Jeff
la source
5

Et <meta>et <link>? Pourquoi ne figurent-ils pas sur cette liste?

En règle générale, ne fermez pas automatiquement les éléments destinés à contenir du contenu, car cela causera certainement des problèmes de navigateur tôt ou tard.

Ceux qui se referment naturellement, comme <br>et <img>, devraient être évidents. Ceux qui ne le sont pas ... ne les fermez pas vous-même!

AmbroseChapelle
la source
4

La dernière fois que j'ai vérifié, les éléments suivants étaient les éléments vides / vides répertoriés dans HTML5.

Valable pour les auteurs: area, base, br, col, command, embed, eventsource, hr, img, input, link, meta, param, source

Non valide pour les auteurs: basefont, bgsound, frame, spacer, wbr

Outre les quelques nouveautés en HTML5, cela devrait vous donner une idée de celles qui pourraient être prises en charge lors de la diffusion de XHTML sous forme de texte / html. (Il suffit de les tester en examinant le DOM produit.)

Quant au XHTML servi en tant qu'application / xhtml + xml (ce qui le rend XML), les règles XML s'appliquent et tout élément peut être vide (même si la DTD XHTML ne peut pas l'exprimer).

Ombre2531
la source
4

Vous devriez jeter un œil aux DTD xHTML , ils sont tous répertoriés. Voici un aperçu rapide de tous les principaux:

<br />
<hr />
<img />
<input />
e-satis
la source
1
Correction et nettoyage du balisage. Attention avec les liens dans ces pages, ils sont lents à charger.
e-satis le
4

Ils sont appelés éléments «vides» en HTML 5. Ils sont répertoriés dans la spécification officielle W3 .

Un élément void est un élément dont le modèle de contenu ne lui permet jamais d'avoir du contenu en aucune circonstance.

Depuis avril 2013, ils sont:

zone, base, br, col, commande, incorporer, hr, img, entrée, keygen, lien, méta, param, source, piste, wbr

Depuis décembre 2018 (HTML 5.2), ils sont:

zone, base, br, col, incorporer, hr, img, entrée, lien, méta, param, source, piste, wbr

mpen
la source
2

Un autre problème de balise à fermeture automatique pour IE est l'élément title. Lorsque IE (juste essayé dans IE7) voit cela, il présente à l'utilisateur une page vierge. Cependant, vous «voyez la source» et tout y est.

<title/>

J'ai vu cela à l'origine lorsque mon XSLT a généré la balise à fermeture automatique.

Kevin Hakanson
la source
Chromium n'aime pas non plus les <title/>tags.
uınbɐɥs
2

Je ne vais pas essayer de trop travailler là-dessus, d'autant plus que la majorité des pages que j'écris sont générées ou que la balise a du contenu. Les deux seuls qui m'ont jamais posé des problèmes lors de leur fermeture automatique sont:

<title/>

Pour cela, je me suis simplement contenté de toujours lui donner une balise de fermeture séparée, car une fois qu'il est là-haut, <head></head>cela ne rend pas vraiment votre code plus compliqué à utiliser de toute façon.

<script/>

C'est le gros problème avec lequel j'ai récemment rencontré des problèmes. Pendant des années, j'avais toujours utilisé des <script/>balises à fermeture automatique lorsque le script provenait d'une source externe. Mais j'ai récemment commencé à recevoir des messages d'erreur JavaScript concernant une forme nulle. Après plusieurs jours de recherche, j'ai trouvé que le problème était (supposément) que le navigateur n'obtenait jamais la <form>balise car il ne réalisait pas que c'était la fin de la <script/>balise. Donc, quand je l'ai transformé en <script></script>tags séparés , tout a fonctionné. Pourquoi différentes pages que j'ai faites sur le même navigateur, je ne sais pas, mais ce fut un grand soulagement de trouver la solution!

Nathan Sokalski
la source
-2

<hr /> est une autre

Darren Kopp
la source