150 votes

HTML : Inclure ou exclure, les balises de fermeture en option ?

Certains HTML1 les balises de fermeture sont en option, 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 interdit de l'être, c'est à dire:

</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 exige que chaque élément a une balise de fermeture. Une balise de fermeture peut être interdit dans le code html, pourtant obligatoire , en xhtml.

En option les balises de fermeture

  • idéalement inclus, mais nous allons à les accepter si vous avez oublié, ou
  • idéalement pas inclus, mais nous allons à les accepter si vous les mettez dans

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

Le HTML 4.01 spec parle de la fermeture des balises d'éléments facultatifs, mais ne dit pas si il est préférable de les inclure, ou préférable de ne pas les inclure.

D'autre part, un article aléatoire sur DevGuru dit:

La balise de fin est facultative. Toutefois, il est recommandé qu'il soit inclus.

La raison que je demande, c'est simplement parce que vous savez qu'il est facultatif pour des raisons de compatibilité; et ils en ont fait (obligatoire | interdit) s'ils pouvaient avoir.

Mettre une autre manière: Ce n'HTML 1, 2, 3 en ce qui concerne ces derniers, désormais facultatif, les balises de fermeture. Ce n'HTML 5? Et que dois - je faire?

Note

Certains éléments HTML sont interdit d'avoir des balises de fermeture. Vous pouvez être en désaccord, mais c'est la norme, et il n'est pas pour le débat. Je veux parler d' option balise de fermeture, et quelle était l'intention.

Notes de bas de page

1HTML 4.01

62voto

porneL Points 42805

Il y a des cas où explicite les balises d'aide, mais il est parfois inutile pedantism.

Notez que la spécification HTML spécifie clairement quand il est valide pour omettre les balises, donc il n'est pas toujours une erreur.

Par exemple vous n'avez jamais besoin d' </body></html>. Jamais personne ne se souvient de mettre <tbody> explicitement (au point que le XHTML fait des exceptions pour elle).

Vous n'avez pas besoin d' </head><body> , sauf si vous avez des DOM-manipuler des scripts qui fait de la recherche <head> (il est alors préférable de fermer explicitement, parce que les règles implicites fin de l' <head> pourrait vous surprendre).

Listes imbriquées sont en fait mieux sans </li>, car il est alors plus difficile de créer errorneous ul > ul arbre.

Valide:

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

Non valide:

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

Et garder à l'esprit que les balises de fin sont implicites si vous essayez de fermer tous les éléments ou pas. Mettre fin balises ne sont pas automatiquement rendre l'analyse plus robuste:

<p>foo <p>bar</p> baz</p>

analyse:

<p>foo</p><p>bar</p> baz

Il ne peut aider lors de la validation de documents.

51voto

aslum Points 1973

Les options sont toutes celles qui devraient être sémantiquement clair où ils sont, sans avoir besoin de la balise de fin. E. g. chaque <li> implique une </li> si il n'y a pas un seul juste avant.

L'interdit de fin des balises tout serait immédiatement suivi par une balise de fin, donc il serait un peu redondant d'avoir à taper <img src="blah" alt="blah"></img> tous les temps.

J'ai presque toujours utiliser les balises facultatives (sauf si j'ai une très bonne raison de ne pas le faire), car il prête à plus lisible et modifiable code.

20voto

Srikar Doddi Points 10611

J'ai ajouté quelques liens ici pour vous aider avec l'histoire de HTML, pour vous de comprendre les diverses contradictions. Ce n'est pas la réponse à votre question, mais vous en saurez plus après la lecture de ces divers recueils.

Quelques extraits de Plonger Dans HTML5:

[L]e fait que "cassé" le balisage HTML toujours travaillé dans les navigateurs web a conduit les auteurs à créer cassé les pages HTML. Beaucoup de débris de pages. Selon certaines estimations, plus de 99% des pages HTML sur le web d'aujourd'hui ont au moins une erreur. Mais parce que ces erreurs ne pas causer des navigateurs affichent des messages d'erreur, jamais personne ne les résout.

Le W3C a vu cela comme un problème fondamental avec le web, et ils se mirent à le corriger. XML, publié en 1997, a rompu avec la tradition de pardonner les clients et a exigé que tous les programmes qui ont consommé de XML doit traiter soi-disant "bien-formation" erreurs fatales. Cette notion de faute sur la première erreur est devenu connu comme "draconienne erreur de manipulation", d'après le chef grec Draco , qui a institué la peine de mort pour des infractions relativement mineures de ses lois. Lorsque le W3C reformulé HTML comme un vocabulaire XML, ils ont exigé que tous les documents servi avec le nouveau application/xhtml+xml type MIME serait soumis à draconiennes d'erreur de manipulation. Si il n'y avait même un seul et unique formation d'erreur dans votre page XHTML [...] les navigateurs web aurait pas d'autre choix que d'arrêter le traitement et l'affichage d'un message d'erreur à l'utilisateur final.

Cette idée n'était pas universellement populaire. Avec une estimation du taux d'erreur de 99% sur les pages existantes, de la possibilité d'afficher les erreurs à l'utilisateur final, et le manque de nouvelles fonctionnalités en XHTML 1.0 et 1.1 pour justifier le coût, les auteurs de sites web fondamentalement ignoré application/xhtml+xml. Mais cela ne signifie pas qu'ils ont ignoré XHTML tout à fait. Oh, certainement pas. L'annexe C de la spécification XHTML 1.0 a donné le web d'auteurs du monde une échappatoire: "Utiliser quelque chose qui ressemble à de syntaxe XHTML, mais garder la servir avec la text/html type MIME." Et c'est exactement ce que des milliers de développeurs de sites web ont fait: ils ont "mis à jour" à la syntaxe XHTML, mais a gardé de le servir avec un texte/html type MIME.

Aujourd'hui encore, des millions de pages web qui prétendent être en XHTML. Ils commencent avec le doctype XHTML sur la première ligne, utilisez les minuscules des noms de balise, utiliser des guillemets autour des valeurs d'attribut, et ajouter une barre oblique après les éléments vides comme <br /> et <hr />. Mais seule une infime fraction de ces pages sont servis avec l' application/xhtml+xml type MIME qui déclencherait XML draconienne du traitement des erreurs. Toute page servi avec un type MIME text/html - indépendamment de doctype, de syntaxe, ou de style de codage - seront analysés à l'aide d'un "pardon" analyseur HTML, qui consiste à ignorer tout de balisage des erreurs, et de ne jamais alerter les utilisateurs finaux (ou quelqu'un d'autre), même si les pages sont techniquement cassé.

XHTML 1.0 inclus cette lacune, mais le XHTML 1.1 fermée, et la jamais finalisé XHTML 2.0 a continué la tradition de l'nécessitant draconiennes d'erreur de manipulation. Et c'est pourquoi il y a des milliards de pages qui prétendent être en XHTML 1.0, et seule une poignée qui prétendent être en XHTML 1.1 (ou XHTML 2.0). Alors, êtes-vous vraiment de l'utilisation du XHTML? Vérifiez votre type MIME. (En fait, si vous ne savez pas quel type MIME que vous utilisez, je peux très bien la garantie que vous êtes toujours à l'aide d' text/html.) Sauf si vous êtes au service de vos pages avec un type MIME application/xhtml+xml, votre soi-disant "XHTML" XML est dans le nom.

[L]es personnes qui ont proposé de l'évolution HTML et HTML les formulaires ont été confrontés à deux choix: abandonner ou de poursuivre leur travail en dehors de la W3C. Ils ont choisi le dernier, a enregistré le whatwg.org de domaine, et, en juin 2004, la CE Groupe de Travail est né.

[L]a CE groupe de travail a été tranquillement à travailler sur un certain nombre d'autres choses, aussi. L'un d'eux était un cahier des charges, initialement baptisé Formulaires Web 2.0, qui a ajouté de nouveaux types de contrôles de formulaires HTML. (Vous en apprendrez plus sur les formulaires web dans Une Forme de Folie.) Un autre était un projet de spécification appelée "Web Applications 1.0", qui a inclus des nouvelles fonctionnalités comme un mode de dessin et la prise en charge native de l'audio et de la vidéo sans plugins.

En octobre 2009, le W3C arrêter le XHTML 2 Groupe de Travail et a publié la déclaration suivante pour expliquer sa décision:

Lorsque le W3C a annoncé le HTML et le XHTML 2 Groupes de Travail en Mars 2007, nous avons indiqué que nous allions continuer à surveiller le marché pour le XHTML 2. W3C reconnaît l'importance d'un signal clair à la communauté à propos de l'avenir de HTML.

Alors que nous reconnaissons la valeur du XHTML 2 du Groupe de Travail des contributions au fil des ans, après discussion avec les participants, le W3C, la direction a décidé de permettre à la charte du Groupe de Travail à expiration à la fin de 2009 et de ne pas le renouveler.

Ceux qui gagnent sont ceux qui navire.

13voto

Quentin Points 325526

La raison que je demande, c'est simplement parce que vous savez qu'il est facultatif pour des raisons de compatibilité; et ils en ont fait (obligatoire | interdit) s'ils pouvaient avoir.

C'est intéressant d'inférence. Ma lecture, c'est que juste au sujet de tout temps une balise pourrait être déduit de manière fiable, la balise est optionnelle. Le dessin suggère que l'intention était de rendre plus facile et plus rapide à écrire.

Ce n'HTML 1, 2, 3 en ce qui concerne ces derniers, désormais facultatif, les balises de fermeture.

La DTD de HTML 2 est incorporé dans la RFC qui, avec l'original de la déclaration DTD HTML, en option, de début et de fin des balises partout dans l'endroit.

HTML 3 a été abandonné (grâce à la guerre des navigateurs) et remplacé par le HTML 3.2 (qui a été conçu pour décrire les état actuel du web).

Ce n'HTML 5?

HTML 5 a été orienté vers un "pavage de la cowpaths" dès le départ.

Et que dois-je faire?

Ah, maintenant que c'est subjectif et argumentatif :)

Certaines personnes pensent que l'explicite les balises sont mieux pour la lisibilité et la maintenabilité par le fait d'être devant les yeux des lecteurs.

Certaines personnes pensent que déduit les balises sont mieux pour la lisibilité et la maintenabilité par la vertu de ne pas encombrer l'éditeur.

8voto

ghoppe Points 10004
<blockquote> <p>Que fait l’HTML 5 ?</p> </blockquote> <p>La réponse à cette question se trouve dans le document de travail du W3C : <a href="http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission">http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission</a></p> <blockquote> <p>Et que dois-je faire ?</p> </blockquote> <p>C’est une question de style. J’ai essayer de jamais omettre les balises de fin parce que ça m’aide à faire preuve de rigueur et de <em>ne pas</em> omettre les balises qui sont nécessaires.</p>

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X