HTML: inclure ou exclure les balises de fermeture facultatives?

149

Certaines balises de fermeture HTML ¹ 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

¹ HTML 4.01

html html4

— Ian Boyd
source

4

Question difficile ... certaines des recommandations du w3c incluent même des exemples qui font les deux: w3.org/TR/html401/struct/global.html#id-and-class Le premier exemple a des </p>balises de fermeture et le second les omet!

— Richard JP Le Guen

Juste pour clarifier - dans le cas des balises interdites dans HTML5, la solution valide "explicite" / XML est de les fermer avec un />, comme <meta charset="utf-8" />même si <meta charset="utf-8">est valide HTML5?

— cboettig

@cboettig Oui. <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" />

— Ian Boyd

@IanBoyd vraiment? en HTML5? Le projet de manuel W3C pour polyglotte html / xhtml dit à utiliser <meta charset="UTF-8"/>avec la balise de fermeture. Sinon, comment polyglotte ou xhtml pourrait-il être validé en html5 et xml?

— cboettig

@cboettig Vous avez raison. Le balisage polyglotte (c'est -à- dire les documents XHTML compatibles HTML ) ne peut pas être du HTML 4.01 valide. HTML5 (encore un travail en cours) a la notion d' éléments Void - éléments qui ne peuvent pas avoir de balise de fin . Vraisemblablement, la plupart des navigateurs sont doux et pardonneront vos erreurs de balisage.

— Ian Boyd

49

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.

— aslum
source

18

je le vois maintenant. <LI>est comme une balle. Personne ne voudrait avoir à encapsuler tout un point à puces <LI>...</LI>. Donc, de cette façon, les LIcorrespondances à 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.

— Ian Boyd

8

Que voulez - vous dire par je presque toujours utiliser les balises optionnelles - voulez - vous dire que vous incluez la balise de fin, ou que vous laissez sortir ? (J'ai eu l'impression que vous l' incluez , quand j'ai lu votre réponse - mais le commentaire ci-dessus par Ian Boyd me donne l'impression que vous l' excluez .)

— KajMagnus

3

@IanBoyd Et pour le dernier paragraphe?

— Pacerier

22

@Pacerier People écrit des paragraphes de texte depuis des centaines d'années. Personne n'a jamais été confus quand un paragraphe se termine.

— Ian Boyd

4

Lien pertinent pour HTML5, pour ceux qui ont trouvé cette réponse en essayant de trouver la documentation de référence réelle: w3.org/TR/html5/syntax.html#optional-tags

— Mike 'Pomax' Kamermans

59

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 un ul > ularbre erroné .

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. L'ajout de 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 aider que lorsque vous validez des documents.

— Kornel
source

4

Attendez, pourquoi n'est <p>foo <p>bar</p> baz</p>pas analysé comme deux pbalises imbriquées ?

— Eric

19

Parce qu'un <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)."

— Ian Boyd

1

@IanBoyd Voulez-vous dire qu'il ne peut pas contenir d'éléments de niveau bloc quelles que soient les règles CSS?

— Pacerier

6

@Pacerier CSS ne peut en aucun cas influencer le DOM. DOM est analysé en premier, puis CSS l'affiche. L' 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).

— Kornel

2

@ anton1980 Non, ce n'est pas la même chose. La gestion des balises de fermeture facultatives omises est clairement spécifiée et fonctionne de manière fiable dans tous les navigateurs compatibles. OTOH un maquillage <t>ne fonctionnera pas comme <title>.

— Kornel le

18

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 :

[L] e fait que le balisage HTML «cassé» fonctionnait toujours dans les navigateurs Web a conduit 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 au moins une erreur. Mais comme ces erreurs ne provoquent pas l'affichage de messages d'erreur visibles par les navigateurs, personne ne les corrige jamais.

Le W3C a vu cela comme un problème fondamental avec le Web et a entrepris de le corriger. XML, publié en 1997, a rompu avec la tradition de pardonner les clients et exigeait que tous les programmes utilisant du XML doivent traiter les erreurs dites de «bonne formation» comme fatales. Ce concept d'échec lors de la première erreur est devenu connu sous le nom de «traitement draconien des erreurs», d'après le dirigeant grec Draco qui a institué la peine de mort pour des infractions relativement mineures à ses lois. Lorsque le W3C a reformulé le HTML en tant que vocabulaire XML, il a exigé que tous les documents servis avec le nouveau application/xhtml+xmltype MIME soient soumis à une gestion des erreurs draconienne. S'il y avait ne serait-ce qu'une seule erreur de bonne formation 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é toujours pré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 veut pas dire qu'ils ont complètement ignoré XHTML. Oh, certainement pas. L'annexe C de la spécification XHTML 1.0 a donné aux auteurs Web du monde entier une faille: "Utilisez quelque chose qui ressemble un peu à la syntaxe XHTML, mais continuez à le servir avec le text/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.

Même aujourd'hui, des millions de pages Web prétendent être 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 à la fin des éléments vides comme <br />et <hr />. Mais seule une infime partie de ces pages est servie avec le application/xhtml+xmltype MIME qui déclencherait la gestion des erreurs draconienne de XML. Toute page servie avec un type MIME text/html- quel que soit le doctype, la syntaxe ou le style de codage - sera analysée à l'aide d'un analyseur HTML «indulgent», ignorant silencieusement les erreurs de balisage et n'alertant jamais les utilisateurs finaux (ou qui que ce soit d'autre) même si les pages sont techniquement cassés.

XHTML 1.0 a inclus cette faille, mais XHTML 1.1 l'a fermée, et le XHTML 2.0 jamais finalisé a continué la tradition d'exiger une gestion des erreurs draconienne. 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étend être XHTML 1.1 (ou XHTML 2.0). Alors, 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 application/xhtml+xml, votre soi-disant "XHTML" est XML dans le nom seulement.

[L] es personnes qui avaient proposé des formulaires HTML et HTML évolutifs ont été confrontées à deux choix: abandonner ou poursuivre leur travail en dehors du W3C. Ils ont choisi ce dernier, enregistré le whatwg.orgdomaine, et en juin 2004, le groupe de travail WHAT est né .

[L] e groupe de travail WHAT travaillait discrètement sur quelques autres choses aussi. L'une d'elles était une spécification, initialement baptisée Web Forms 2.0 , 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 brouillon de spécification appelé «Applications Web 1.0», qui comprenait de nouvelles fonctionnalités majeures comme un canevas de dessin en mode direct et une prise en charge native de l' audio et de la 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 de 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 à la fin de 2009 et de ne pas la renouveler.

Ceux qui gagnent sont ceux qui expédient.

— Srikar Doddi
source

12

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.

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.

Qu'a 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 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).

Que fait HTML 5?

HTML 5 a été orienté vers «ouvrir les chemins de vache» dès le départ.

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é 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.

— Quentin
source

1

+1 Je n'avais pas pensé à la notion de "déduit de manière fiable". Donc, cela prône l'idée qu'il n'y avait pas vraiment d'intention dans un sens ou dans l'autre. J'ai supposé que la spécification tentait d'être aussi compatible que possible avec le contenu HTML existant et les spécifications HTML.

— Ian Boyd

Désolé, Dave, je l'ai donné à aslum; il a besoin du représentant :) Mais vous avez la même idée, avec plus de contenu lié et cité. Mais bonne réponse.

— Ian Boyd

8

Que fait HTML 5?

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

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 qui sont nécessaires.

— ghoppe
source

+1 pour le lien vers le brouillon de spécification HTML 5 et la section appropriée. Mais html 5 ne dit pas d'une manière ou d'une autre.

— Ian Boyd

6

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. :)

— John
source

5

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.

— Gabe
source

2

Richard: Lorsque vous avez des structures profondément imbriquées, il est beaucoup plus facile pour vous de trouver des erreurs car les balises de fermeture donnent plus d'informations sur l'intention.

— Gabe

1

Je pense que «les balises de fermeture donnent plus d'informations sur l'intention» est la meilleure réponse concise à cette question. Argue une bonne raison claire d'une manière ou d'une autre.

— squarecandy

4

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.

— user1777246
source

Je peux difficilement accepter d'omettre les balises de fin facultatives, mais je trouve plutôt une mauvaise idée d'omettre les guillemets sur les attributs. Vous risquez ainsi que votre site se brise dans certains navigateurs. Si vous avez des fichiers html de 800 Ko, vous faites quelque chose de très mal.

— Christoph

2

@Christoph: Omettre les balises de fin facultatives (comme </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.

— Konrad Borowski

2

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?

— Richard JP Le Guen
source

2

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?

— RideauChien
source

1

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.

— MiguelR
source

Pourriez-vous donner un exemple de HTML si délicat? D'après mon expérience, les balises de fin facultatives ne sont pas aussi trompeuses.

— Kornel le

Je me souviens avoir eu un problème avec IE7 il y a quelques années où j'ai trouvé une balise li d'ouverture sur une ligne distincte du texte qu'elle contenait, sans li de fermeture, IE7 traitait toutes les balles comme une seule grosse balle. mettre la balise et le texte sur une seule ligne, ou fermer la balise, résoudrait le problème. Je ne peux pas sembler le reprocher maintenant, cependant, cela avait probablement aussi quelque chose à voir avec le CSS en jeu. mais je ne vous reprocherais pas de considérer cela comme un "j'ai totalement une petite amie ... au Canada!" récit.

— MiguelR

0

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.

— Joel Mueller
source

1

Je ne suis pas d'accord; la notion de bonne formation par opposition à la validité est un concept uniquement XML et devient inutile lorsque vous avez des éléments dont les balises fermées sont interdites .

— Richard JP Le Guen

1

Je comprends cela, mais l'élément DOM rendu a à la fois un début et une fin, même si votre balise HTML n'en a pas. Si vous incluez une <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.

— Joel Mueller

C'est un point intéressant mais je ne suis toujours pas d'accord; les balises de fermeture sont facultatives car elles seraient obligatoires et donc implicites selon les règles de validation ... donc lorsque l'analyseur atteint un point où il doit y avoir une balise de fermeture selon la validation, ne peut-on pas soutenir que la tâche de consommation une balise de fermeture (lorsqu'elle est présente) le ralentirait simplement

— Richard JP Le Guen

@Richard - Je suppose que cela dépend de la mise en œuvre réelle dans un navigateur particulier, mais j'ai du mal à créditer l'idée qu'être explicite sur l'endroit où vous voulez qu'un élément se termine serait pire pour les performances que de dire au navigateur de le comprendre. tu.

— Joel Mueller

@RichardJPLeGuen Je suppose que tout dépend de l'apparence exacte des règles. Lorsque vous fermez un </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.

— maaartinus

-1

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>.

— Matthew Wilson
source

1

J'espérais des conseils sur la décision de conception originale, et qu'ils auraient fait x s'ils l'avaient pu.

— Ian Boyd

Quelle est la différence entre <td>et <li>qui ne vous dérange pas <li>? Pour moi, il y a peu de différence.

— ghoppe

Il n'y a pas de différence technique, c'est purement subjectif. J'ai l'impression de mieux lire le HTML si je ferme td et tr. Mais je n'ai jamais ressenti le besoin de li.

— Matthew Wilson

-2

Pour les types de fermeture interdits, utilisez une syntaxe comme: <img />Avec le />pour fermer la balise qui est acceptée en xml

— Dani
source

1

Cela ne fonctionne pas en HTML4 (il correspond à une syntaxe SGML obscure qui fait quelque chose de légèrement différent). En HTML5, c'est autorisé, mais sans signification.

— Kornel le