Les balises à fermeture automatique (non nulles) sont-elles valides en HTML5?


670

Le validateur W3C n'aime pas les balises à fermeture automatique (celles qui se terminent par " />") sur les éléments non vides . (Les éléments vides sont ceux qui ne contiennent jamais de contenu.) Sont-ils toujours valides en HTML5?

Quelques exemples d' éléments annulés acceptés :

<br />
<img src="" />
<input type="text" name="username" />

Quelques exemples d' éléments non nuls rejetés :

<div id="myDiv" />
<span id="mySpan" />
<textarea id="someTextMessage" />

Remarque:
Le validateur W3C accepte en fait les balises à fermeture automatique nulles: l'auteur avait à l'origine un problème à cause d'une simple faute de frappe ( \>au lieu de />); cependant, les balises à fermeture automatique ne sont pas valides à 100% en HTML5 en général, et les réponses expliquent la question des balises à fermeture automatique dans diverses versions HTML.


2
@Ben: oh, désolé, je pense que tu as raison. Dans ce cas, j'ai mal compris la question d'origine, je pensais que l'OP voulait savoir si les balises à fermeture automatique étaient valides du tout en HTML5. Mais cela signifie qu'il vient de faire des fautes de frappe dans son code, ou qu'il ne savait pas comment écrire correctement les balises à fermeture automatique, ce qui a du sens que le validateur W3C ait marqué son code comme non valide.
Sk8erPeter

16
Pour gagner du temps pour les futurs lecteurs: oui, la syntaxe de la question est incorrecte et non, vous ne devez pas la modifier. Le PO a expliqué de manière explicite et justifiée pourquoi . Puisqu'il a donné lieu aux erreurs de validation qui ont provoqué cette question, la syntaxe ne doit pas être corrigée.
Jordan Grey

2
Êtes-vous toujours en train de vous battre pour savoir dans quelle direction les barres obliques doivent être dirigées? Allons.
BoltClock

3
@BoltClock Yup, toujours en train de se battre. Les gars: si cette question posait des questions \>, elle devrait être fermée comme une question fixe-ma-faute de frappe inutile. Les réponses s'adressent toutes />. La />version est la seule utile. Laisse faire.
Gilles 'SO- arrête d'être méchant'

1
Ensuite, la question doit être reformulée, car le validateur W3C accepte en fait les balises à fermeture automatique. Il est difficile de reformuler la question de cette manière sans compromettre son intégrité par rapport à l'intention initiale. Par conséquent, si nous voulons adhérer aux règles de SO, nous devrons peut-être sacrifier la clarté dans des questions telles que celle-ci, même s'il semble que la modification de la question est la seule chose sensée à faire, pour le plus grand bien de moyenne. Nous pourrions commencer une autre discussion sur les méta, s'il y a beaucoup d'autres questions sur un problème similaire.
osa

Réponses:


1238
  • En HTML 4 , <foo /(oui, sans aucun >) signifie <foo>(ce qui conduit au <br />sens <br>>(ie <br>&gt;) et au <title/hello/sens <title>hello</title>). Il s'agit d'une règle SGML que les navigateurs ont très mal pris en charge, et la spécification conseille aux auteurs d'éviter la syntaxe .

  • En XHTML , <foo />signifie<foo></foo> . Il s'agit d'une règle XML qui s'applique à tous les documents XML. Cela dit, XHTML est souvent servi comme text/htmlce qui (historiquement au moins) est traité par les navigateurs en utilisant un analyseur différent de celui des documents servis application/xhtml+xml. Le W3C fournit des directives de compatibilité à suivre pour XHTML as text/html. (Essentiellement: n'utilisez la syntaxe de balise à fermeture automatique que lorsque l'élément est défini comme VIDE (et que la balise de fin a été interdite dans la spécification HTML)).

  • En HTML5 , la signification de <foo /> dépend du type d'élément .

    • Sur les éléments HTML qui sont désignés comme des éléments vides (essentiellement "Un élément qui existait avant HTML5 et auquel il était interdit d'avoir du contenu"), les balises de fin sont simplement interdites. La barre oblique à la fin de la balise de début est autorisée, mais n'a aucune signification. Ce n'est que du sucre syntaxique pour les personnes (et les surligneurs de syntaxe) qui sont accro au XML.
    • Sur les autres éléments HTML, la barre oblique est une erreur, mais la récupération d'erreur amènera les navigateurs à l'ignorer et à traiter la balise comme une balise de démarrage normale. Cela se terminera généralement par une balise de fin manquante, ce qui fera que les éléments suivants seront des enfants au lieu de frères et sœurs.
    • Les éléments étrangers (importés à partir d'applications XML telles que SVG) le traitent comme une syntaxe à fermeture automatique.

24
" ... qui sont accros à XML. ". Vous semblez suggérer que la conformité XML est mauvaise. Pourtant, le résultat final en HTML5 semble être que nous devons quand même toujours traiter les crochets angulaires (c'est-à-dire quelque chose avec la plupart des inconvénients de XML), alors qu'il rend plus difficile l'utilisation d'outils basés sur XML (par exemple, les outils de modèle ou divers processeurs ). Même d'un point de vue de la génération, il semblerait que <object data="..." />et <img src="..."></src>ne sont pas OK, alors <object data="..."></object>et <img src="..." />sont, ce qui le rend plus difficile la cohérence de l' outil. Cela ressemble à une situation perdante.
Bruno

7
@Bruno - HTML est antérieur à XML. Les efforts pour amener les gens à passer à XHTML ont échoué. Avec text/html, les navigateurs ne donnent aucune signification particulière à la barre oblique, donc l'inclure ne sert à rien. Il n'est là que pour le faire ressembler davantage à XML pour les personnes qui ne peuvent pas sortir de l'habitude.
Quentin

6
@Quentin Je ne suis pas entièrement en désaccord. Je trouve juste un peu dommage qu'un équivalent XML valide ne soit pas nécessairement HTML5 valide (par exemple <img ...></img>au lieu de <img ...>ou <img ... />). Étant donné que HTML5 est effectivement moins contraignant en général (peut-être pourquoi XHTML a échoué), il aurait très bien pu tolérer quelque chose comme <img ...></img>. Malheureusement, ce n'est pas le cas, donc un générateur de modèles basé sur XML doit savoir distinguer la production d'éléments vides ou d'éléments à fermeture automatique: vous ne pouvez même pas avoir une règle pour dire écrire tous les éléments vides <tag></tag>.
Bruno

3
XHTML a échoué avant que HTML 5 ne soit à l'horizon, et vous ne pouvez pas avoir des éléments vides de forme longue car la correction d'erreur du navigateur antérieure à XHTML ferait des choses comme le traitement </br>comme <br>tel <br></br>serait un double saut de ligne. (et la compatibilité descendante avec le mauvais balisage du monde réel (comme </br>) est l'un des objectifs de conception de HTML 5).
Quentin

1
FROM W3C: Éléments vides: area, base, br, col, embed, hr, img, input, keygen, link, meta, param, source, track, wbr "Les éléments vides n'ont qu'une balise de début; les balises de fin ne doivent pas être spécifiées pour les éléments vides. " w3.org/TR/html5/syntax.html#void-elements
Fabio Nolasco

406

Comme l'a souligné Nikita Skvortsov, un div à fermeture automatique ne sera pas validé. En effet, un div est un élément normal , pas un élément vide .

Selon la spécification HTML5 , les balises qui ne peuvent pas avoir de contenu (appelées éléments vides ) peuvent se fermer automatiquement *. Cela inclut les balises suivantes:

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

Le "/" est complètement facultatif sur les balises ci-dessus, cependant il <img/>n'est pas différent de <img>, mais <img></img>n'est pas valide.

* Remarque: les éléments étrangers peuvent également se fermer automatiquement, mais je ne pense pas que cela soit dans la portée de cette réponse.


1
Les outils de développement d'IE10 me donnent «HTML1500: la balise ne peut pas se fermer automatiquement. Utilisez une balise de fermeture explicite». sur la ligne <meta charset = "UTF-8" /> Une idée pourquoi ce serait?
James à Indy

Ok, j'ai découvert que les balises à fermeture automatique ne devraient pas avoir la barre oblique (et la supprimer corrige mon erreur). Cite: tiffanybbrown.com/2011/03/23/…
James in Indy

La spécification a changé. Désormais, les éléments "void" ou "auto-fermant" ne doivent pas inclure la barre oblique, lorsqu'ils sont utilisés comme doctype HTML 5. Cependant, s'il est servi en tant que XHTML, la barre oblique de fermeture peut être requise (consultez la documentation dans ce cas). En pratique, les pages s'affichent généralement comme prévu, même si la fermeture /a été incluse, mais cela n'est pas garanti (cela dépend du navigateur qui réécrit le code pour vous et l'interprète comme vous le souhaitiez.) De plus, si pour une raison quelconque, votre page doit passer la validation HTML 5, elle pourrait ne pas passer si vous fermez les balises pour les éléments vides.
SherylHohman

En ce qui concerne le commentaire de @ SherylHohman, je ne crois pas que la spécification a changé (ou si c'est le cas, elle a changé en arrière). Voir w3.org/TR/html5/syntax.html#start-tags (8.1.2.1.6) - les éléments void (ou étrangers) peuvent toujours inclure la barre oblique.
ChrisC

63

En pratique, l'utilisation de balises à fermeture automatique en HTML devrait fonctionner exactement comme vous vous y attendez. Mais si vous êtes préoccupé par l'écriture de HTML5 valide , vous devez comprendre comment l'utilisation de ces balises se comporte dans les deux formes de syntaxe que vous pouvez utiliser. HTML5 définit à la fois une syntaxe HTML et une syntaxe XHTML, qui sont similaires mais pas identiques. Celui qui est utilisé dépend du type de support envoyé par le serveur Web.

Plus que probablement, vos pages sont servies en tant que text/html, ce qui suit la syntaxe HTML plus clémente. Dans ces cas, HTML5 autorise certaines balises de début à avoir une option / avant de se terminer>. Dans ces cas, le / est facultatif et ignoré, <hr>et <hr />sont donc identiques. La spécification HTML appelle ces "éléments vides" et donne une liste des éléments valides. À strictement parler, l'option / n'est valide que dans les balises de début de ces éléments void; par exemple, <br />et <hr />sont HTML5 valides, mais <p />ne le sont pas.

La spécification HTML5 établit une distinction claire entre ce qui est correct pour les auteurs HTML et pour les développeurs de navigateurs Web, le deuxième groupe étant tenu d'accepter toutes sortes de syntaxe "héritée" non valide. Dans ce cas, cela signifie que les navigateurs compatibles HTML5 accepteront les balises auto-fermées illégales, comme <p />, et les rendront comme vous vous y attendez probablement. Mais pour un auteur, cette page ne serait pas valide en HTML5. (Plus important encore, l'arborescence DOM que vous obtenez en utilisant ce type de syntaxe illégale peut être sérieusement vissée; les <span />balises auto-fermées , par exemple, ont tendance à gâcher beaucoup les choses ).

(Dans le cas inhabituel où votre serveur sait comment envoyer des fichiers XHTML en tant que type XML MIME, la page doit être conforme à la DTD XHTML et à la syntaxe XML. Cela signifie que des balises à fermeture automatique sont requises pour les éléments définis comme tels.)


31
<p /> sera traité comme une balise d'ouverture, pas une balise auto-fermée. Cela signifie que le reste du document sera traité comme faisant partie de l'élément P. Ce n'est pas ce que j'attends "probablement", et cela produira un gâchis sérieux sur n'importe quelle page non triviale.
mhsmith

12

HTML5 se comporte essentiellement comme si la barre oblique de fin n'était pas là. Il n'y a pas de balise à fermeture automatique dans la syntaxe HTML5.

  • Les balises à fermeture automatique sur des éléments non vides comme <p/>, <div/>ne fonctionneront pas du tout. La barre oblique de fin sera ignorée et celles-ci seront traitées comme des balises d'ouverture. Cela risque d'entraîner des problèmes d'imbrication.

    Cela est vrai indépendamment du fait qu'il y ait un espace devant la barre oblique: <p />et <div />ne fonctionnera pas non plus pour la même raison.

  • Étiquettes à fermeture automatique de vide des éléments tels <br/>ou <img src="" alt=""/> ne fonctionnera, mais seulement parce que le slash est ignoré, et dans ce cas qui arrive à entraîner le comportement correct.

Le résultat est que tout ce qui fonctionnait dans votre ancien "XHTML 1.0 a servi de texte / html" continuera de fonctionner comme avant: les barres obliques de fin sur les balises non-void n'y étaient pas acceptées non plus alors que la barre oblique de fin sur les éléments void fonctionnait.

Une dernière remarque: il est possible de représenter un document HTML5 en XML, et cela est parfois surnommé "XHTML 5.0". Dans ce cas, les règles de XML s'appliquent et les balises à fermeture automatique seront toujours gérées. Il devrait toujours être servi avec un type mime XML.


5

Les balises à fermeture automatique sont valides en HTML5, mais pas obligatoires.

<br>et <br />sont tous les deux très bien.


12
Selon les spécifications HTML5, la syntaxe à fermeture automatique ( />) ne peut pas être utilisée sur un élément HTML non nul.
naXa

3
La question portait sur les balises à fermeture automatique sur les éléments non nuls , comme <p/>ou <div/>.
thomasrutter

2
Au départ, la question ne portait pas spécifiquement sur les éléments non nuls. C'était plus comme, pouvez-vous toujours utiliser <... />comme en XHTML ou devez-vous supprimer le /en HTML5. La question a été modifiée plusieurs fois par la suite.
Nick

Quoi qu'il en soit, la réponse est que la barre oblique sera ignorée, ce qui cassera les éléments non déclarés vides, mais sera compatible avec les éléments vides.
thomasrutter

4

Je serais très prudent avec les balises à fermeture automatique comme le montre cet exemple:

var a = '<span/><span/>';
var d = document.createElement('div');
d.innerHTML = a
console.log(d.innerHTML) // "<span><span></span></span>"

Mon intuition aurait été à la <span></span><span></span>place


2
Ceci est décrit dans la réponse acceptée:On other [than void] HTML elements, the slash is an error, but error recovery will cause browsers to ignore it and treat the tag as a regular start tag. This will usually end up with a missing end tag causing subsequent elements to be children instead of siblings.
Palec

-1

Cependant, juste pour mémoire, ce n'est pas valide:

<address class="vcard">
  <svg viewBox="0 0 800 400">
    <rect width="800" height="400" fill="#000">
  </svg>
</address>

Et une barre oblique ici le rendrait à nouveau valide:

    <rect width="800" height="400" fill="#000"/>

1
C'est parce que svg est écrit en xml, pas en html. Il utilise différentes règles d'analyse
Electric Coffee
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.