Certaines balises de fermeture HTML 1 sont facultatives , à savoir:
</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>Remarque: à ne pas confondre avec les balises fermantes dont l'inclusion est interdite , à savoir:
</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>Remarque: xhtml est différent du HTML. xhtml est une forme de xml, qui nécessite que chaque élément ait une balise de fermeture. Une balise de fermeture peut être interdite en html, mais obligatoire en xhtml.
Les balises de fermeture facultatives sont-elles
- idéalement inclus , mais nous les accepterons si vous les avez oubliés, ou
- idéalement non inclus, mais nous les accepterons si vous les mettez
En d'autres termes, dois- je les inclure ou ne pas les inclure?
La spécification HTML 4.01 indique que la fermeture des balises d'élément est facultative , mais ne dit pas s'il est préférable de les inclure, ou préférable de ne pas les inclure.
D'un autre côté, un article aléatoire sur DevGuru dit :
La balise de fin est facultative. Cependant, il est recommandé de l'inclure.
La raison pour laquelle je pose la question est que vous savez que c'est facultatif pour des raisons de compatibilité; et ils les auraient rendus ( obligatoires | interdits ) s'ils avaient pu.
En d'autres termes: qu'est-ce que HTML 1, 2, 3 a fait par rapport à ces balises de fermeture, désormais facultatives. Que fait HTML 5? Et que dois- je faire?
Remarque
Il est interdit à certains éléments en HTML d'avoir des balises de fermeture. Vous n'êtes peut-être pas d'accord avec cela, mais c'est la spécification, et ce n'est pas à débattre. Je demande des balises de fermeture facultatives et quelle était l'intention.
Notes de bas de page
1 HTML 4.01
</p>balises de fermeture et le second les omet!/>, comme<meta charset="utf-8" />même si<meta charset="utf-8">est valide HTML5?<meta charset="utf-8" />est un html invalide , il doit l' être<meta charset="utf-8">. D'autre part , le xhtml<meta charset="tuf-8">n'est pas valide , il doit être<meta charset="utf-8" /><meta charset="UTF-8"/>avec la balise de fermeture. Sinon, comment polyglotte ou xhtml pourrait-il être validé en html5 et xml?Réponses:
Les options facultatives sont toutes celles qui devraient être sémantiquement claires là où elles se terminent, sans avoir besoin de l'étiquette de fin. EG chacun
<li>implique un</li>s'il n'y en a pas un juste avant lui.Les balises de fin interdites seraient toutes immédiatement suivies de leur balise de fin, il serait donc redondant de devoir taper à
<img src="blah" alt="blah"></img>chaque fois.J'utilise presque toujours les balises optionnelles (sauf si j'ai une très bonne raison de ne pas le faire) car elles donnent un code plus lisible et modifiable.
la source
<LI>est comme une balle. Personne ne voudrait avoir à encapsuler tout un point à puces<LI>...</LI>. Donc, de cette façon, lesLIcorrespondances à ce que les gens écriraient naturellement pendant le balisage. Sames opte pour une marque de paragraphe (<P>), dans le traitement de texte, vous ajoutez une marque de paragraphe au début d'un paragraphe; et pas à la fin de chacun aussi. Donc, dans cette interprétation, les balises de fermeture sont facultatives car aucune personne normale ne penserait à les avoir. De plus, l'élément lui-même n'a pas de contenu - l'élément est le contenu.Il y a des cas où les balises explicites aident, mais parfois c'est du pédantisme inutile.
Notez que la spécification HTML spécifie clairement quand il est valide d'omettre les balises, ce n'est donc pas toujours une erreur.
Par exemple, vous n'en avez jamais besoin
</body></html>. Personne ne se souvient jamais de le mettre<tbody>explicitement (au point que XHTML en a fait des exceptions).Vous n'en avez pas besoin à
</head><body>moins que vous n'ayez des scripts de manipulation DOM qui recherchent réellement<head>(alors il vaut mieux le fermer explicitement, car les règles pour la fin implicite de<head>pourraient vous surprendre).Les listes imbriquées sont en fait mieux sans
</li>, car il est alors plus difficile de créer unul > ularbre erroné .Valide:
Invalide:
Et gardez à l'esprit que les balises de fin sont implicites, que vous essayiez de fermer tous les éléments ou non. L'ajout de balises de fin ne rendra pas automatiquement l'analyse plus robuste:
analysera comme:
Cela ne peut aider que lorsque vous validez des documents.
la source
<p>foo <p>bar</p> baz</p>pas analysé comme deuxpbalises imbriquées ?<P>élément ne peut pas contenir d'éléments de niveau bloc et<P>est un élément de niveau bloc. From ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "L'élément P représente un paragraphe. Il ne peut pas contenir d'éléments de niveau bloc (y compris P lui-même)."blockaffichage CSS est une chose complètement différente du contenu au niveau du bloc HTML (il se trouve que la plupart des éléments au niveau du bloc HTML sont affichés par défaut sous forme de blocs CSS).<t>ne fonctionnera pas comme<title>.J'ajoute ici quelques liens pour vous aider avec l'histoire du HTML, pour que vous compreniez les différentes contradictions. Ce n'est pas la réponse à votre question, mais vous en saurez plus après avoir lu ces différents résumés.
Quelques extraits de Dive Into HTML5 :
la source
C'est une inférence intéressante. D'après ma lecture, à peu près à chaque fois qu'une balise peut être déduite de manière fiable, la balise est facultative. La conception suggère que l'intention était de le rendre rapide et facile à écrire.
La DTD pour HTML 2 est intégrée dans la RFC qui, avec la DTD HTML d' origine , a des balises de début et de fin facultatives partout.
HTML 3 a été abandonné (grâce à la guerre des navigateurs) et remplacé par HTML 3.2 (qui a été conçu pour décrire l'état alors actuel du Web).
HTML 5 a été orienté vers «ouvrir les chemins de vache» dès le départ.
Ah, maintenant c'est subjectif et argumentatif :)
Certaines personnes pensent que les balises explicites sont meilleures pour la lisibilité et la maintenabilité car elles sont devant les yeux des lecteurs.
Certaines personnes pensent que les balises inférées sont meilleures pour la lisibilité et la maintenabilité car elles n'encombrent pas l'éditeur.
la source
La réponse à cette question se trouve dans le document de travail du W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission
C'est une question de style. J'essaie de ne jamais omettre les balises de fin car cela m'aide à être rigoureux et à ne pas omettre les balises qui sont nécessaires.
la source
Si c'est superflu, laissez-le de côté.
Si cela sert un objectif (même un objectif apparemment insignifiant, comme apaiser votre IDE ou apaiser vos yeux), laissez-le.
Il est rare dans une spécification bien définie de voir des éléments facultatifs qui n'affectent pas le comportement. À l'exception des "commentaires", bien sûr. Mais la spécification HTML est moins une spécification de conception, et plus un document de l'état des principales implémentations actuelles. Ainsi, lorsqu'un élément est facultatif en HTML et qu'il semble ne servir à rien, nous pouvons supposer que la nature facultative est simplement la documentation d'une bizarrerie dans un navigateur spécifique.
En regardant la section RFC de spécification HTML-5 liée ci-dessus, vous voyez que les balises optionnelles sont étrangement liées à la présence de commentaires! Cela devrait vous dire que les auteurs ne portent pas de chapeaux design. Ils jouent plutôt le jeu de «documenter les bizarreries» dans les principales implémentations. Nous ne pouvons donc pas prendre les spécifications trop au sérieux à cet égard.
Donc, la solution est: ne vous inquiétez pas. Passez à quelque chose qui compte vraiment. :)
la source
Je pense que la meilleure réponse est d'inclure des balises de fermeture pour la lisibilité ou la détection d'erreur. Cependant, si vous avez beaucoup de HTML généré (par exemple, des tableaux de données), vous pouvez économiser une bande passante importante en omettant les balises facultatives.
la source
Ma recommandation est d'omettre la plupart des balises de fermeture facultatives et tous les attributs facultatifs avec lesquels vous pouvez vous en tirer. De nombreux IDE se plaindront de sorte que vous ne pourrez peut-être pas vous en passer, mais c'est généralement mieux pour une taille de fichier plus petite et moins d'encombrement. Si vous avez des générateurs de code, omettez définitivement les balises de fin, car vous pouvez en obtenir une bonne réduction de taille. Habituellement, cela n'a pas vraiment d'importance dans un sens ou dans l'autre.
Mais quand cela compte, agissez en conséquence. Sur certains de mes travaux récents, j'ai pu réduire la taille de mon HTML rendu de 1,5 Mo à 800 Ko en éliminant la plupart des attributs de fin et de valeur redondants générés pour la balise ouverte, où le texte de l'élément était le même que le valeur. J'ai environ 200 balises. Je pourrais implémenter cela d'une autre manière entièrement, mais ce serait plus de travail ($$$), donc cela me permet de rendre facilement la page plus réactive.
Juste par curiosité, j'ai trouvé que si je supprimais les guillemets autour des attributs qui n'en avaient pas besoin, je pouvais économiser 20 Ko, mais mon IDE (Visual Studio) ne l'aime pas. J'ai également été surpris de constater que l'ID très long généré par ASP.NET représente 20% de mon fichier.
L'idée que nous pourrions jamais obtenir une fraction pertinente de HTML strictement valide était erronée en premier lieu, alors faites ce qui fonctionne le mieux pour vous et vos clients. La plupart des outils que j'ai jamais vus ou utilisés diront qu'ils génèrent du xhtml, mais ils ne fonctionnent pas vraiment à 100%, et il n'y a aucun avantage à une adhésion stricte de toute façon.
la source
</p>ou</li>) est parfaitement acceptable selon les spécifications HTML. Si le navigateur ne comprend pas cela, c'est un problème avec le navigateur.Personnellement, je suis fan de XHTML et, comme ghoppe, "j'essaie de ne jamais omettre les balises de fin car cela m'aide à être rigoureuse et à ne pas omettre les balises qui sont nécessaires."
mais
Si vous utilisez délibérément HTML 4.n, on ne peut pas dire que leur inclusion facilite la consommation du document, car la notion de bonne forme par opposition à la validité est un concept XML, et vous perdez cet avantage lorsque vous interdire certaines balises fermées. Le seul problème est donc la validité ... et si c'est toujours valable sans eux ... autant économiser la bande passante, non?
la source
L'utilisation de balises de fin facilite la gestion des fragments car leur comportement ne dépend pas des éléments frères. Cette seule raison devrait être suffisamment convaincante. Est-ce que quelqu'un s'occupe plus de documents html monolithiques?
la source
Dans certains langages entre accolades comme C #, vous pouvez omettre les accolades autour d'une instruction if si ses deux lignes seulement. par exemple...
if ([condition])
[code]
mais vous ne pouvez pas faire ça ...
if ([condition])
[code]
[code]
la troisième ligne ne fera pas partie de l'instruction if. cela nuit à la lisibilité, et des bogues peuvent être facilement introduits et difficiles à trouver.
pour les mêmes raisons, je ferme toutes les balises. les balises comme la balise img doivent encore être fermées, mais pas avec une balise de fermeture séparée.
la source
Si vous écriviez un analyseur HTML, serait-il plus facile d'analyser du HTML qui inclut des balises de fermeture facultatives, ou du HTML qui n'en contient pas? Je pense que les balises de fermeture facultatives présentes faciliteraient les choses, car je n'aurais pas à déduire où la balise de fermeture devrait être.
Pour cette raison, j'inclus toujours les balises de fermeture facultatives - sur la théorie que ma page pourrait s'afficher plus rapidement, car je crée moins de travail pour l'analyseur HTML du navigateur.
la source
<li>balise sans balise de fermeture, le navigateur devra à un moment donné décider où se termine l'élément et agir comme si vous aviez mis une balise de fin à ce stade. Cela peut être une quantité relativement insignifiante de logique, mais "certains" est toujours plus que "aucun" et je ne pense pas qu'il soit déraisonnable de supposer que laisser de côté les balises de fin optionnelles fait plus de travail pour le navigateur que de les inclure.</table>et que votre pile contient<table><tbody><tr><td>, vous pouvez simplement tout fermer jusqu'à ce que vous trouviez le fichier<table>. De même pour l'ouverture<p>dans un contexte sans horloge. Mais il peut y avoir des cas beaucoup plus difficiles, je ne sais pas.Faites ce que vous pensez pour rendre le code plus lisible et maintenable.
Personnellement, je serais toujours enclin à fermer
<td>et<tr>, mais je ne m'en soucierais jamais<li>.la source
<td>et<li>qui ne vous dérange pas<li>? Pour moi, il y a peu de différence.Pour les types de fermeture interdits, utilisez une syntaxe comme:
<img />Avec le/>pour fermer la balise qui est acceptée en xmlla source