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

https://stackoverflow.com/questions/3008593

26-09-2019
|

Question

Certains HTML ¹ balises de fermeture sont option , à savoir:

</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 à inclure, i.e..

</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, ce qui nécessite tous les éléments ont une balise de fermeture. Une balise de fermeture peut être interdit en html, mais obligatoire xhtml.

Les balises de fermeture en option

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

En d'autres termes, devrait Je les inclure, ou devrais-je pas les inclure?

Le HTML 4.01 parle de spécifications sur les balises élément de fermeture étant option , mais ne dit pas s'il est préférable de les inclure, ou préférable de ne pas les inclure.

Par contre, un article au hasard sur DevGuru dit :

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

La raison pour laquelle je demande est parce que vous venez de savoir il est en option pour des raisons de compatibilité; et ils auraient fait leur ( obligatoire | interdit ). si elles pourraient avoir

En d'autres termes: Qu'est-ce que HTML 1, 2, 3 font en ce qui concerne ces derniers, maintenant en option, les balises de fermeture. Qu'est-ce que HTML 5 faire? Et que devrait I faire?

Remarque

Certains éléments HTML sont interdit 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 pour le débat. Je demande au sujet de option balises de fermeture, et quelle était l'intention.

Notes

¹ HTML 4.01

La solution

Les optionnelles sont tous ceux qui devraient être sémantiquement clairement où ils finissent, sans avoir besoin de la balise de fin. PAR EXEMPLE. chaque <li> implique une </li> s'il n'y a pas un droit devant elle.

Les balises de fin interdites tout serait suivie immédiatement par leur balise de fin de sorte qu'il serait redondant de sorte d'avoir à taper <img src="blah" alt="blah"></img> chaque fois.

Je presque toujours utiliser les balises facultatives (à moins d'avoir une très bonne raison de ne pas) parce qu'il prête à plus de code lisible et actualisable.

Autres conseils

Il y a des cas où des balises explicites aident, mais parfois il est inutile pédantisme.

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

Par exemple, vous ne devez jamais </body></html>. Personne ne se souvient jamais de mettre <tbody> explicitement (au point que XHTML fait exception pour elle).

Vous n'avez pas besoin </head><body> sauf si vous avez des scripts DOM manipulation qui recherche réellement <head> (il est préférable de fermer explicitement, parce que les règles pour la fin implicite de <head> pourrait vous surprendre).

autres listes sont en fait mieux sans </li>, car il est plus difficile de créer l'arbre errorneous de ul > ul.

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 la fin des balises sont implicites si vous essayez de fermer tous les éléments ou non. Putting balises de fin ne signifie pas automatiquement l'analyse syntaxique plus robuste:

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

analysera comme:

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

Il ne peut qu'aider lors de la validation des documents.

J'ajoute ici quelques liens 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 avoir lu ces différentes digestions.

Quelques extraits de Plongez dans HTML5 :

[T], il fait que le balisage « cassé » HTML toujours travaillé dans les navigateurs Web a conduit les auteurs à créer des pages HTML brisées. Beaucoup de pages brisées. Selon certaines estimations, plus de 99% des pages HTML sur le web d'aujourd'hui ont au moins une erreur en eux. Mais parce que ces erreurs ne causent pas de navigateurs pour afficher les messages d'erreur visibles, personne ne les fixe jamais.

Le W3C a vu cela comme un problème fondamental avec le web, et ils partirent pour la corriger. XML, publié en 1997, a rompu la tradition des clients pardonnant et a exigé que tous les programmes qui consommaient XML doivent traiter soi-disant « bien formedness » comme des erreurs fatales. Ce concept de défaut sur la première erreur est devenu connu sous le nom « gestion des erreurs draconienne », après que le chef grec Draco qui a institué la peine de mort pour des infractions relativement mineures de ses lois. Lorsque le W3C HTML reformulé comme un vocabulaire XML, ils ont exigé que tous les documents servis avec le nouveau type MIME application/xhtml+xml serait soumis à la gestion des erreurs draconienne. S'il y avait même une seule erreur bien formedness dans votre navigateur web page XHTML [...] aurait pas d'autre choix que d'arrêter le traitement et afficher un message d'erreur à l'utilisateur final.

Cette idée n'a pas été 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 la pénurie de nouvelles fonctionnalités en XHTML 1.0 et 1.1 pour justifier le coût, les auteurs web application/xhtml+xml essentiellement ignoré. Mais cela ne signifie pas qu'ils ont ignoré XHTML tout à fait. Oh, certainement pas. Annexe C de la spécification XHTML 1.0 a donné aux auteurs web du monde une échappatoire: «Utilisez quelque chose qui ressemble un peu comme la syntaxe XHTML, mais continuer à servir avec le type MIME text/html » Et c'est exactement ce que des milliers de développeurs web ont fait: ils « mis à jour » à la syntaxe XHTML, mais avec service maintenu un type MIME text / html.

Aujourd'hui encore, des millions de pages Web prétendent être XHTML. Ils commencent par le doctype XHTML sur la première ligne, utilisez les noms de balises minuscules, utilisez des guillemets autour des valeurs d'attributs, et ajoutez un slash après des éléments vides comme <br /> et <hr />. Mais seule une infime fraction de ces pages sont servis avec le type MIME application/xhtml+xml qui déclencherait la gestion des erreurs draconienne de XML. Toute page servi avec un type MIME de text/html - quel que soit doctype, la syntaxe ou le style de codage - sera analysé à l'aide d'un analyseur HTML « pardonner », en ignorant silencieusement des erreurs de marquage, et jamais d'alerter les utilisateurs finaux (ou quelqu'un d'autre), même si le pages sont techniquement cassé.

XHTML 1.0 inclus cette lacune, mais XHTML 1.1 fermé, et le XHTML 2.0 ne finalisé a poursuivi la tradition d'exiger la gestion des erreurs draconienne. Et voilà 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). Alors, utilisez-vous vraiment XHTML? Vérifiez votre type MIME. (En fait, si vous ne savez pas quel type MIME que vous utilisez, je peux à peu près garantievous utilisez encore text/html.) Sauf si vous êtes au service de vos pages avec un type MIME de application/xhtml+xml, votre soi-disant « XHTML » est XML en nom.

[L] des gens qui avaient proposé des formulaires HTML et HTML évolution ont été confrontés à deux choix: abandonner, ou poursuivre leur travail en dehors du W3C. Ils ont choisi ce dernier, a enregistré le whatwg.org domaine, et en Juin 2004, Groupe de travail est né QU'EST-CE .

[L] Quel est le groupe de travail travaillait tranquillement sur quelques autres choses aussi. L'un d'eux était une spécification, initialement baptisée , qui a ajouté de nouveaux types de contrôles pour les formulaires HTML. (Vous en apprendrez plus sur les formulaires web Une forme de folie .) Un autre était un projet de spécification appelée « Applications Web 1.0 », qui comprend de nouvelles fonctionnalités majeures comme une toile de dessin en mode direct et un support natif pour audio et vidéo sans plug-ins .

En Octobre 2009, le W3C fermer le XHTML 2 Groupe de travail et a fait la déclaration pour expliquer leur décision :


Lorsque W3C a annoncé le HTML et XHTML 2 groupes de travail en Mars 2007, nous avons indiqué que nous continuerons à suivre le marché du XHTML 2. W3C reconnaît l'importance d'un signal clair à la communauté sur l'avenir du HTML.

Nous reconnaissons la valeur du XHTML 2 contributions du Groupe de travail au cours des années, après discussion avec les participants, la direction du W3C a décidé de laisser expirer la charte du groupe de travail à la fin de 2009 et de ne pas le renouveler.


Ceux qui gagnent sont ceux qui navire.

La raison pour laquelle je demande est parce que vous savez qu'il est facultatif pour des raisons de compatibilité; et ils les auraient fait (obligatoire | interdit). si elles pourraient avoir

C'est une conclusion intéressante. Ma lecture est que presque chaque fois qu'une étiquette pourrait être fiable déduit, l'étiquette 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 faire en ce qui concerne ces derniers, maintenant en option, les balises de fermeture.

Le DTD pour HTML 2 est noyé dans la RFC qui, avec DTD HTML , a démarrage en option et des étiquettes de fin dans tous les sens .

HTML 3 a été abandonnée (grâce à la guerre des navigateurs) et remplacé par HTML 3.2 (qui a été conçu pour décrire l'état actuel de la puis Web).

Qu'est-ce que HTML 5 faire?

HTML 5 a été orienté vers "ouvrant les" chemins des vaches dès le départ.

Et que dois-je faire?

Ah, maintenant est subjective et argumentatif:)

Certaines personnes pensent que les balises explicites sont meilleurs pour la lisibilité et la maintenabilité en vertu d'être devant les yeux des lecteurs.

Certaines personnes pensent que les balises sont inférées mieux pour la lisibilité et la maintenabilité en vertu de ne pas encombrer l'éditeur.

Qu'est-ce que HTML 5 faire?

La réponse à cette question est dans le travail du W3C Projet: http://www.w3.org/TR/html5/syntax .html # syntaxe-tag-omission

Et que dois-je faire?

Il est une question de style. J'essaie d'omettre jamais balises de fin, car il me permet d'être rigoureux et pas omettent des balises qui sont nécessaires.

S'il est superflu, laissez-le.

Si elle sert un objectif (même un but apparemment trivial, comme votre IDE ou apaiser vos yeux apaiser), le laisser dans.

Il est rare dans une spécification bien définie pour voir les éléments facultatifs qui ne touchent pas le comportement. À l'exception des « commentaires », bien sûr. Mais la spécification HTML est moins d'une spécification de conception, et plus d'un document de l'état des implémentations actuelles majeures. Ainsi, lorsqu'un élément est facultatif en HTML et il semble servir à rien, on peut deviner que la nature facultative est simplement la documentation d'une bizarrerie dans le navigateur spécifique.

En regardant la section RFC spécification HTML-5 lié ci-dessus, vous voyez que les balises facultatives sont étrangement liés à la présence de commentaires! Cela devrait vous dire que les auteurs ne sont pas des chapeaux de conception. Ils jouent le jeu à la place de « document les bizarreries » dans les grandes implémentations. Donc, nous ne pouvons pas prendre trop au sérieux les spécifications à cet égard.

Alors, la solution est: Ne vous inquiétez pas. Passez à quelque chose qui importe réellement. :)

Je pense que la meilleure réponse est d'inclure des balises de fermeture pour la lisibilité ou la détection d'erreur. Toutefois, si vous avez beaucoup de HTML généré (disons, tableaux de données), vous pourriez économiser la bande passante importante en supprimant les balises optionnelles.

Ma recommandation est que vous ne spécifiez pas les balises les plus proches en option, et tous les attributs facultatifs que vous pouvez vous contenter. De nombreux IDEs se plaindront vous afin de ne pas être en mesure de sortir avec omettant certains d'entre eux, mais il est généralement préférable pour la taille du fichier et moins d'encombrement. Si vous avez des générateurs de code omettent certainement là balises de fin parce que vous pouvez obtenir une réduction de bonne taille de celui-ci. En général, il ne compte pas vraiment d'une façon ou l'autre.

Mais quand il ne importe agir alors sur elle. Sur certains travaux récents de mes j'ai pu réduire la taille de mon rendu HTML de 1,5 Mo à 800 Ko en éliminant la plupart des la fin générée et les attributs valeur redondante pour la balise ouverte, où le texte de l'élément est la même que la valeur. J'ai environ 200 tags. Je pourrais mettre en œuvre cette autre manière tout à fait, mais ce serait plus de travail ($$$), donc cela me permet de faire facilement la page plus réactive.

Juste par curiosité, je trouve que si j'enlevé des guillemets autour des attributs qui ne en ont pas besoin que je pouvais économiser 20 Ko, mais mon IDE (Visual Studio) ne l'aime pas. J'ai aussi été surpris de constater que l'ID vraiment long que ASP.NET génère compte pour 20% de mon dossier.

L'idée que nous ne pourrions jamais obtenir une fraction pertinente de HTML strictement valable était erronée en premier lieu, donc faire tout ce qui fonctionne le mieux pour vous et vos clients. La plupart des outils que j'ai jamais vu ou utilisé diront qu'ils génèrent xhtml, mais ils ne fonctionnent pas vraiment 100%, et il n'y a aucun avantage au strict respect de toute façon.

Personnellement, je suis un fan de XHTML et, comme ghoppe, «J'essaie d'omettre jamais balises de fin, car il me aide à être rigoureux et ne pas omettre les balises qui sont nécessaires. »

Si vous délibérément à l'aide 4.n HTML, on ne peut affirmer que l'inclusion les rend plus facile à consommer le document, la notion de bien-formedness par opposition à la validité est un concept XML, et vous perdez que bénéficier lorsque vous interdire certaines balises proches. Donc, la seule question devient validité ... et si elle est toujours valide sans eux ... vous pourriez aussi bien économiser la bande passante, non?

En utilisant les balises de fin rend le traitement des fragments plus facile parce que leur comportement ne dépend pas des éléments frères et soeurs. Cette seule raison devrait être assez convaincant. Est-ce que quelqu'un traite des documents html monolithique plus?

Dans certains langages de ACCOLADE comme C #, vous pouvez omettre les accolades autour d'une instruction if si ses deux lignes. par exemple ...

si ([condition])
[Code]

mais vous ne pouvez pas le faire ...

si ([condition])
[Code]
[Code]

la troisième ligne ne sera pas une partie de l'instruction if. ça fait mal la lisibilité et les bugs peuvent être facilement introduit et difficile à trouver.

pour les mêmes raisons, je ferme tous les tags. balises comme la balise img ne doivent encore être fermés, mais pas avec une balise de fermeture séparée.

Si vous écrivez un analyseur HTML, serait-il plus facile à analyser HTML inclus balises de fermeture en option, ou HTML qui ne fonctionne pas? Je pense que les balises de fermeture en option présence rendrait plus facile, car je ne voudrais pas en déduire où la balise de fermeture doit être.

Pour cette raison, je toujours inclure les balises de fermeture en option - sur la théorie selon laquelle ma page pourrait rendre plus rapide, que je crée moins de travail pour l'analyseur HTML du navigateur

Faites ce que vous vous sentez rend le code plus lisible et maintenable.

Personnellement, je serais toujours enclin à fermer <td> et <tr>, mais je ne vous embêtez pas avec <li>.

Pour les types de fermeture interdits utiliser la syntaxe comme: <img /> Avec la /> pour fermer la balise qui est acceptée dans xml

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow