HTML: inclure ou exclure des balises de fermeture facultatives?
Certains HTML 1 les balises de fermeture sont facultatif, c'est-à-dire:
</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>
Remarque: À ne pas confondre avec les balises de fermeture qui sont interdites à être inclus, à savoir:
</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>
Remarque: xhtml est différent de HTML. xhtml est une forme de xml, qui nécessite un élément chaque possède une balise de fermeture. Une balise de fermeture peut être interdite en html, mais obligatoire en xhtml.
Les balises de fermeture facultatives
- idéalement inclus, mais nous les accepterons si vous les avez oubliés, ou
- idéalement pas inclus, mais nous les accepterons si vous les mettez
En d'autres termes, devrait Je les inclue, ou dois-je pas les inclure?
La spécification HTML 4.01 parle de la fermeture facultative des balises d'élément , mais ne dit pas s'il est préférable de les inclure, ou préférable de ne pas les inclure.
D'autre part, n article aléatoire sur DevGuru dit :
La balise de fin est facultative. Cependant, il est recommandé de l'inclure.
La raison pour laquelle je demande, c'est parce que vous venez de - savoir c'est facultatif pour des raisons de compatibilité; et ils les auraient rendus ( obligatoires | interdits ) s'ils avaient pu avoir.
Autrement dit: qu'a fait HTML 1, 2, 3 en ce qui concerne ces balises de fermeture, désormais facultatives. Que fait HTML 5? Et que doit faire [~ # ~] i [~ # ~]?
Remarque
Certains éléments en HTML sont interdits d'avoir des balises de fermeture. Vous pouvez être en désaccord avec cela, mais c'est la spécification, et ce n'est pas sujet à débat. Je demande à propos de facultatif fermeture des balises, et quelle était l'intention.
Notes de bas de page
1HTML 4.01
Les options sont toutes celles qui devraient être sémantiquement claires là où elles se terminent, sans avoir besoin de la balise de fin. PAR EXEMPLE. chaque <li> implique un </li> s'il n'y en a pas juste avant.
Les balises de fin interdites seraient toutes immédiatement suivies de leur balise de fin, il serait donc assez redondant de devoir taper <img src="blah" alt="blah"></img> à chaque fois.
J'utilise presque toujours les balises facultatives (sauf si j'ai une très bonne raison de ne pas le faire), car il se prête à un code plus lisible et actualisable.
Il y a des cas où les balises explicites aident, mais parfois c'est un pédantisme inutile.
Notez que la spécification HTML spécifie clairement quand il est valide d'omettre les balises, donc ce n'est pas toujours une erreur.
Par exemple, vous n'avez jamais besoin de </body></html>. Personne ne se souvient jamais de mettre <tbody> explicitement (au point que XHTML en a fait des exceptions).
Vous n'avez pas besoin de </head><body> sauf si vous avez des scripts de manipulation DOM qui recherchent réellement <head> (il est préférable de le fermer explicitement, car les règles de fin implicite de <head> pourrait vous surprendre).
Les listes imbriquées sont en fait mieux sans </li>, car il est alors plus difficile de créer des erreurs ul > ul arbre.
Valide:
<ul>
<li>item
<ul>
<li>item
</ul>
</ul>
Invalide:
<ul>
<li>item</li>
<ul>
<li>item</li>
</ul>
</ul>
Et gardez à l'esprit que les balises de fin sont implicites, que vous essayiez de fermer tous les éléments ou non. Mettre des balises de fin ne rendra pas automatiquement l'analyse plus robuste:
<p>foo <p>bar</p> baz</p>
analysera comme:
<p>foo</p><p>bar</p> baz
Cela ne peut être utile que lorsque vous validez des documents.
J'ajoute ici quelques liens pour vous aider dans 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.
- Comment en sommes-nous arrivés là? - Plongez dans HTML5
- L'histoire du Web
- Bref historique du HTML
- Historique HTML - HTML WG Wiki
Quelques extraits de Dive Into HTML5 :
[L] e fait que le balisage HTML "cassé" fonctionnait toujours dans les navigateurs Web a amené les auteurs à créer des pages HTML cassées. Beaucoup de pages cassées. Selon certaines estimations, plus de 99% des pages HTML sur le Web contiennent aujourd'hui au moins une erreur. Mais comme ces erreurs n'entraînent pas l'affichage de messages d'erreur visibles par les navigateurs, personne ne les corrige.
Le W3C a vu cela comme un problème fondamental avec le web, et ils ont décidé de le corriger. XML, publié en 1997, a rompu avec la tradition de pardonner aux clients et a exigé que tous les programmes qui consommaient XML doivent traiter les erreurs dites de "bonne forme" comme fatales. Ce concept d'échec sur la première erreur est devenu connu sous le nom de "gestion d'erreur draconienne", après le leader grec Draco qui a institué la peine de mort pour des infractions relativement mineures à ses lois. Lorsque le W3C a reformulé HTML en tant que vocabulaire XML, il a exigé que tous les documents soient servis avec le nouveau
application/xhtml+xmlLe type MIME serait sujet à une gestion draconienne des erreurs. S'il y avait même une seule erreur de bonne forme dans votre page XHTML, les navigateurs Web n'auraient d'autre choix que d'arrêter le traitement et d'afficher un message d'erreur à l'utilisateur final.Cette idée n'était pas universellement populaire. Avec un taux d'erreur estimé à 99% sur les pages existantes, la possibilité omniprésente d'afficher des erreurs à l'utilisateur final et le manque de nouvelles fonctionnalités dans XHTML 1.0 et 1.1 pour justifier le coût, les auteurs Web ont fondamentalement ignoré
application/xhtml+xml. Mais cela ne signifie pas qu'ils ont complètement ignoré le XHTML. Oh, certainement pas. L'annexe C de la spécification XHTML 1.0 a donné aux auteurs Web du monde une faille: "Utilisez quelque chose qui ressemble un peu à la syntaxe XHTML, mais continuez à la servir avec letext/htmlType MIME. "Et c'est exactement ce que des milliers de développeurs Web ont fait: ils ont" mis à niveau "la syntaxe XHTML mais ont continué à la servir avec un type MIME texte/html.Aujourd'hui encore, des millions de pages Web prétendent être du XHTML. Ils commencent par le doctype XHTML sur la première ligne, utilisent des noms de balises en minuscules, utilisent des guillemets autour des valeurs d'attribut et ajoutent une barre oblique après les éléments vides comme
<br />et<hr />. Mais seule une infime partie de ces pages est diffusée avec leapplication/xhtml+xmlType MIME qui déclencherait la gestion draconienne des erreurs de XML. Toute page diffusée avec un type MIME detext/html- indépendamment du doctype, de la syntaxe ou du style de codage - sera analysé à l'aide d'un analyseur HTML "indulgent", ignorant silencieusement les erreurs de balisage et n'alertant jamais les utilisateurs finaux (ou quiconque) même si les pages sont techniquement cassées.XHTML 1.0 incluait cette échappatoire, mais XHTML 1.1 l'a fermée et le XHTML 2.0 jamais finalisé a poursuivi la tradition d'exiger une gestion draconienne des erreurs. Et c'est pourquoi il y a des milliards de pages qui prétendent être XHTML 1.0, et seulement une poignée qui prétendent être XHTML 1.1 (ou XHTML 2.0). Utilisez-vous vraiment XHTML? Vérifiez votre type MIME. (En fait, si vous ne savez pas quel type MIME vous utilisez, je peux à peu près garantir que vous utilisez toujours
text/html.) À moins que vous ne diffusiez vos pages avec un type MIME deapplication/xhtml+xml, votre soi-disant "XHTML" est uniquement de nom XML.
[L] es personnes qui avaient proposé l'évolution des formulaires HTML et HTML étaient confrontées à deux choix: abandonner ou continuer leur travail en dehors du W3C. Ils ont choisi ce dernier, enregistré le
whatwg.orgdomain, et en juin 2004, WHAT Working Group est né .
[L] e QUEL groupe de travail travaillait tranquillement sur quelques autres choses aussi. L'un d'eux était une spécification, initialement appelée Web Forms 2. , qui ajoutait de nouveaux types de contrôles aux formulaires HTML. (Vous en apprendrez plus sur les formulaires Web dans A Form of Madness .) Un autre était un projet de spécification appelé "Web Applications 1.0", qui comprenait de nouvelles fonctionnalités majeures comme n dessin en mode direct canvas et support natif pour audio et vidéo sans plugins .
En octobre 2009, le W3C a fermé le groupe de travail XHTML 2 et a publié cette déclaration pour expliquer sa décision :
Lorsque le W3C a annoncé les groupes de travail HTML et XHTML 2 en mars 2007, nous avons indiqué que nous continuerions à surveiller le marché du XHTML 2. Le W3C reconnaît l'importance d'un signal clair à la communauté sur l'avenir du HTML.
Bien que nous reconnaissions la valeur des contributions du Groupe de travail XHTML 2 au fil des ans, après discussion avec les participants, la direction du W3C a décidé d'autoriser l'expiration de la charte du Groupe de travail fin 2009 et de ne pas la renouveler.
Ceux qui gagnent sont ceux qui expédient.
La raison pour laquelle je demande, c'est parce que vous savez que c'est facultatif pour des raisons de compatibilité; et ils l'auraient fait (obligatoire | interdit) s'ils avaient pu.
C'est une inférence intéressante. Ma lecture de celui-ci est qu'à 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 la rendre rapide et facile à écrire.
Qu'ont fait HTML 1, 2, 3 en ce qui concerne ces balises de fermeture, désormais facultatives.
La DTD pour HTML 2 est intégrée dans le RFC qui, avec l'original HTML DTD , a des balises de début et de fin facultatives toutes sur le lieu.
HTML 3 a été abandonné (grâce aux guerres des navigateurs) et remplacé par HTML 3.2 (qui a été conçu pour décrire l'état actuel du Web).
Que fait HTML 5?
HTML 5 a été conçu dès le départ pour "paver les sentiers de la vache".
Et que dois-je faire?
Ah, maintenant c'est subjectif et argumentatif :)
Certaines personnes pensent que les balises explicites sont meilleures pour la lisibilité et la maintenabilité en raison d'être devant les yeux des lecteurs.
Certaines personnes pensent que les balises inférées sont meilleures pour la lisibilité et la maintenabilité du fait qu'elles n'encombrent pas l'éditeur.
Que fait HTML 5?
La réponse à cette question se trouve dans le projet de travail du W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission
Et que dois-je faire?
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 nécessaires.
S'il est superflu, laissez-le de côté.
Si cela sert un but (même un but apparemment trivial, comme apaiser votre IDE ou apaiser vos yeux), laissez-le dedans.
Il est rare dans une spécification bien définie de voir les é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, mais plutôt un document sur 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 la spécification HTML-5 liée ci-dessus, vous voyez que les balises facultatives 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 implémentations majeures. Nous ne pouvons donc pas prendre la spécification trop au sérieux à cet égard.
Donc, la solution est: ne le transpirez pas. Passez à quelque chose qui compte vraiment. :)
Je pense que la meilleure réponse est d'inclure des balises de fermeture pour la lisibilité ou la détection des erreurs. Cependant, si vous avez beaucoup de code HTML généré (par exemple, des tableaux de données), vous pouvez économiser une bande passante importante en omettant les balises facultatives.
Ma recommandation est que vous omettez la plupart des balises de fermeture facultatives et tous les attributs facultatifs avec lesquels vous pouvez vous en sortir. De nombreux IDE se plaindront de sorte que vous ne pourrez peut-être pas vous en passer en omettant certains d'entre eux, mais il est généralement préférable 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 générés de fin et de valeur redondante 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 toute autre manière, mais ce serait plus de travail ($$$), donc cela me permet de rendre la page plus réactive facilement.
Par simple curiosité, j'ai découvert que si je supprimais des guillemets autour d'attributs qui n'en avaient pas besoin, je pouvais économiser 20 Ko, mais mon IDE (Visual Studio) ne l'aime pas. J'étais aussi 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 de toute façon aucun avantage à une adhésion stricte.
L'utilisation de balises de fin facilite le traitement des fragments car leur comportement ne dépend pas des éléments frères. Cette raison à elle seule devrait être suffisamment convaincante. Quelqu'un s'occupe-t-il plus de documents html monolithiques?
Personnellement, je suis un fan de XHTML et, comme ghoppe, "j'essaie de ne jamais omettre les balises de fin car cela m'aide à être rigoureux et à ne pas omettre les balises nécessaires."
mais
Si vous utilisez délibérément HTML 4.n, on ne peut pas prétendre 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. Donc le seul problème devient la validité ... et si c'est toujours valable sans eux ... vous pourriez aussi bien économiser la bande passante, non?
Dans certains langages à accolades comme C #, vous pouvez omettre les accolades autour d'une instruction if si ses deux seules lignes sont longues. par exemple...
si ([condition])
[Code]
mais vous ne pouvez pas faire ça ...
si ([condition])
[Code]
[Code]
la troisième ligne ne fera pas partie de l'instruction if. cela nuit à la lisibilité et les 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 toujours être fermées, mais pas avec une balise de fermeture distincte.
Si vous écriviez un analyseur HTML, serait-il plus facile d'analyser du HTML qui comprenait des balises de fermeture facultatives, ou du HTML qui ne le fait pas? Je pense que les balises de fermeture facultatives présentes faciliteraient la tâche, 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.