HTML: inclure ou exclure des balises de fermeture facultatives?

Certaines balises de fermeture HTML 1 sont facultatives , à savoir:

   

Note: Ne pas confondre avec les balises fermantes dont l’inclusion est interdite , c’est-à-dire:

   

Remarque: xhtml est différent de HTML. xhtml est une forme de xml, qui requirejs que chaque élément ait une balise de fermeture. Une balise de fermeture peut être interdite en html, mais obligatoire dans xhtml .

Sont 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 dans

En d’autres termes, devrais- je les inclure ou devrais-je ne pas les inclure?

La spécification HTML 4.01 stipule que la fermeture des balises d’élément est facultative , mais ne dit pas s’il est préférable de les inclure ou de ne pas les inclure.

D’autre part, un article au hasard 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 faits ( obligatoire | interdit ) s’ils le pouvaient.

En d’autres termes: qu’est-ce que HTML 1, 2, 3 fait en ce qui concerne ces balises de fermeture, désormais facultatives. Que fait HTML 5? Et que dois- je faire?

Remarque

Certains éléments en HTML ne sont pas autorisés à avoir des balises de fermeture. Vous pouvez ne pas être d’accord avec cela, mais c’est la spécification, et ce n’est pas à débattre. Je pose des questions sur les balises de fermeture facultatives et sur l’intention.

Notes de bas de page

1 HTML 4.01

Les options sont toutes celles qui doivent être sémantiquement claires là où elles se terminent, sans avoir besoin de la balise de fin. EG chaque

  • implique un s’il n’y en a pas juste avant.

    Les balises de fin interdites seraient immédiatement suivies de leur balise de fin, il serait donc redondant de devoir taper à chaque fois http://soffr.miximages.com/html/blah .

    J’utilise presque toujours les balises optionnelles (sauf si j’ai une très bonne raison de ne pas le faire), car cela donne un code plus lisible et modifiable.

    Il y a des cas où les étiquettes 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, donc ce n’est pas toujours une erreur.

    Par exemple, vous n’avez jamais besoin de . Personne ne se souvient jamais de mettre

    explicitement (au point que XHTML en a fait des exceptions).

    Vous n’avez pas besoin de moins que vous ayez des scripts de manipulation DOM qui recherchent réellement (il vaut mieux le fermer explicitement, car les règles pour la fin implicite de pourraient vous surprendre).

    En fait, les listes nestedes se portent mieux sans , car il est alors plus difficile de créer un arbre errorneous ul > ul .

    Valide:

     
    • item
      • item

    Invalide:

     
    • item
    • item

    Et n’oubliez pas que les balises de fin sont impliquées, que vous essayiez de fermer tous les éléments ou non. Mettre des balises de fin ne rend pas automatiquement l’parsing plus robuste:

     

    foo

    bar

    baz

    va parsingr comme:

     

    foo

    bar

    baz

    Cela ne peut que vous aider lorsque vous validez des documents.

    J’ajoute quelques liens ici pour vous aider dans l’histoire du HTML, pour que vous puissiez comprendre 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 est-ce qu’on est arrivés ici? – Plongez dans HTML5
    • L’histoire du Web
    • Bref historique du HTML
    • Historique HTML – HTML WG Wiki

    Quelques extraits de Dive Into HTML5 :

    Le fait que le balisage HTML «cassé» fonctionnait encore 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 ils ont entrepris de le corriger. XML, publié en 1997, a rompu avec la tradition de pardonner aux clients et a exigé que tous les programmes utilisant du XML doivent traiter les erreurs dites «bien formées» comme fatales. Ce concept d’échec de la première erreur est devenu connu sous le nom de «traitement des erreurs draconien», après le chef 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, ils ont exigé que tous les documents servis avec le nouveau type MIME application/xhtml+xml soient soumis à une gestion des erreurs draconienne. S’il y avait même une seule erreur de 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é toujours présente d’afficher des erreurs pour l’utilisateur final et la pénurie de nouvelles fonctionnalités dans XHTML 1.0 et 1.1 pour justifier le coût, les auteurs Web ont essentiellement 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 créé une faille dans le monde des auteurs Web: «Utilisez quelque chose qui ressemble à la syntaxe XHTML, mais continuez à le servir avec le type MIME text/html .» Et c’est exactement ce que des milliers de développeurs Web ont fait. : ils ont été «mis à niveau» vers la syntaxe XHTML mais ont continué à le servir avec un type MIME text / 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 minuscules, utilisent des guillemets autour des valeurs d’atsortingbut et ajoutent une barre oblique après les éléments vides tels que
    et


    . Mais seule une infime fraction de ces pages est servie avec le type MIME application/xhtml+xml qui déclencherait la gestion des erreurs draconiennes de XML. Toute page servie avec un type MIME de text/html – quels que soient le type de docteurs, la syntaxe ou le style de codage – sera analysée à l’aide d’un parsingur HTML tolérant, ignorant silencieusement les erreurs de marquage et ne alertant jamais les utilisateurs finaux. si les pages sont techniquement brisées.

    XHTML 1.0 incluait cette faille, mais XHTML 1.1 l’a fermé, et le XHTML 2.0, qui n’a jamais été finalisé, poursuivait la tradition de la gestion des erreurs draconienne. Et c’est pourquoi il existe 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). Donc, vous utilisez vraiment XHTML? Vérifiez votre type MIME. (En fait, si vous ne savez pas quel type MIME vous utilisez, je peux vous garantir que vous utilisez toujours text/html .) Sauf si vous servez vos pages avec un type d’ application/xhtml+xml MIME application/xhtml+xml , votre soi-disant «XHTML» est un nom XML uniquement.

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

    Le groupe de travail travaillait discrètement sur quelques autres choses. L’une d’entre elles était une spécification, initialement appelé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 projet de spécification appelé «Web Applications 1.0», qui incluait de nouvelles fonctionnalités majeures comme un canevas de dessin en mode direct et un support natif pour l’ audio et 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 à surveiller le marché du XHTML 2. Le W3C reconnaît l’importance d’un signal clair pour la communauté concernant l’avenir du HTML.

    Bien que nous reconnaissions la valeur des consortingbutions du groupe de travail XHTML 2 au fil des ans, après discussion avec les participants, la direction du W3C a décidé de laisser expirer la charte du groupe de travail fin 2009 et non de la renouveler.

    Ceux qui gagnent sont ceux qui expédient.

    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 faits (obligatoire | interdit) s’ils le pouvaient.

    C’est une inférence intéressante. Ma lecture de cela est que à peu près à tout moment une balise peut être inférée de manière fiable, la balise est facultative. La conception suggère que l’intention était de le rendre rapide et facile à écrire.

    Qu’est-ce que HTML 1, 2, 3 fait en ce qui concerne ces balises de fermeture, désormais facultatives.

    La DTD pour HTML 2 est intégrée à la RFC qui, avec la DTD HTML originale, comporte des balises de début et de fin facultatives partout.

    HTML 3 a été abandonné (grâce aux guerres des navigateurs) et remplacé par HTML 3.2 (conçu pour décrire l’état actuel du Web).

    Qu’est-ce que HTML 5 fait?

    HTML 5 visait à «paver les chemins des vaches» 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é en étant en face des yeux des lecteurs.

    Certaines personnes pensent que les étiquettes présumées sont meilleures en termes de lisibilité et de facilité de maintenance car elles n’encombrent pas l’éditeur.

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

    Si c’est superflu, laissez-le de côté.

    Si cela sert à quelque chose (même un but apparemment anodin, 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 n’affectant pas le comportement. À l’exception des “commentaires”, bien sûr. Mais la spécification HTML est moins une spécification de conception, et plus d’un document sur l’état des principales implémentations actuelles. Ainsi, lorsqu’un élément est facultatif en HTML et qu’il semble inutile, nous pouvons supposer que la nature facultative est simplement la documentation d’une bizarrerie dans un navigateur spécifique.

    En regardant la section HTML-5 spec RFC 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. Au lieu de cela, ils jouent au jeu de “documenter les bizarreries” dans les principales implémentations. Nous ne pouvons donc pas prendre la spécification trop au sérieux à cet égard.

    Donc, la solution est la suivante: ne pas transpirer. Passez à quelque chose qui compte réellement. 🙂

    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 tables de données), vous pouvez économiser de la bande passante en omettant les balises facultatives.

    Je vous recommande d’omettre la plupart des balises de fermeture facultatives et tous les atsortingbuts facultatifs que vous pouvez utiliser. De nombreux IDE vont se plaindre, de sorte que vous ne pourrez peut-être pas vous en passer mais il est généralement préférable de réduire la taille des fichiers et de réduire l’encombrement. Si vous avez des générateurs de code, omettez définitivement les balises de fin parce que vous pouvez en obtenir une bonne réduction de la taille. Habituellement, cela n’a pas vraiment d’importance dans un sens ou dans l’autre.

    Mais quand c’est important, alors 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 atsortingbuts de valeur finale et redondante générés pour la balise ouverte, où le texte de l’élément était identique à celui du tag. valeur. J’ai environ 200 tags. Je pourrais entièrement implémenter cela, mais ce serait plus de travail ($$$), ce qui me permet de rendre la page plus réactive.

    Juste par curiosité, j’ai constaté que si je supprimais les guillemets autour d’atsortingbuts qui n’en avaient pas besoin, je pourrais économiser 20 Ko, mais mon IDE (Visual Studio) ne l’aime pas. J’ai également été surpris de constater que le très long identifiant généré par ASP.NET représente 20% de mon fichier.

    L’idée que nous puissions jamais obtenir une fraction de code HTML valide était erronée en premier lieu, alors faites de votre mieux pour vous et vos clients. La plupart des outils que j’ai jamais vus ou utilisés disent qu’ils génèrent du xhtml, mais ils ne fonctionnent pas vraiment à 100%, et le respect ssortingct ne présente aucun avantage.

    Personnellement, je suis 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 affirmer que les inclure facilite la consommation du document, car la notion de bien-être par opposition à la validité est un concept XML, et vous perdez cet avantage lorsque vous interdire certains tags proches. Donc, le seul problème devient validité … et si elle est toujours valable sans eux … vous pourriez aussi bien économiser la bande passante, non?

    L’utilisation de balises de fin facilite le traitement des fragments car leur comportement ne dépend pas d’éléments apparentés. Cette seule raison devrait être suffisamment convaincante. Quelqu’un utilise-t-il des documents HTML monolithiques?

    Dans certains langages en crochets comme C #, vous pouvez omettre les accolades autour d’une instruction if si ce ne sont que deux lignes de long. par exemple…

    si ([condition])
    [code]

    mais tu ne peux 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 séparée.

    Si vous écriviez un parsingur HTML, serait-il plus facile d’parsingr le code HTML contenant des balises de fermeture facultatives ou le code HTML qui ne l’est pas? Je pense que les balises de fermeture facultatives présentes faciliteraient la tâche, car je n’aurais pas à déduire où devrait se trouver la balise de fermeture.

    Pour cette raison, j’inclus toujours les balises de fermeture facultatives – sur la théorie selon laquelle ma page pourrait être rendue plus rapidement, car je crée moins de travail pour l’parsingur HTML du navigateur.

    Faites ce que vous estimez rendre le code plus lisible et maintenable.

    Personnellement, je serais toujours enclin à fermer

    et

    , mais je ne me soucierais jamais de

  • .

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