Décision de conception - pourquoi générer <p> sans </p>?


14

tl; dr

Certains programmes largement utilisés, qui génèrent du HTML, ne génèrent que des balises de paragraphe d'ouverture et non de fermeture, en supposant que le navigateur ferme correctement les paragraphes.

À première vue, il me semble que l'hypothèse selon laquelle les navigateurs fermeront correctement les paragraphes n'est pas correcte. Mon interprétation est-elle correcte? Plus généralement, quels compromis impliquent ce type de décision?


En parcourant le code source de moinmoin, la ligne de code suivante a attiré mon attention:

# We only open those tags and let the browser auto-close them:
_auto_closing_tags = set(['p'])

( source )

Après avoir lu le reste de l'implémentation, je me suis convaincu que oui, en effet, lorsque moinmoin génère du code html pour l'une de ses pages, il générera correctement les balises d'ouverture de paragraphe, le cas échéant, tout en évitant délibérément les balises de fermeture de paragraphe (bien que cela soit trivialement possible).

Pour mon cas d'utilisation spécifique, plutôt inhabituel, ce comportement n'est pas correct. Je suis tenté de soumettre un rapport de bogue et / ou de changer le comportement. Cependant, il semble que cette décision de conception ait été réfléchie. Je ne connais pas assez bien les subtilités du standard html, ou les différentes implémentations de navigateur, pour pouvoir dire si c'est un comportement correct en général, et j'ai le sentiment que mon instinct pour corriger / changer ce comportement pourrait être mal orienté.

Ce code fait-il une hypothèse valide sur les implémentations du navigateur? Le code HTML généré est-il valide? Plus généralement, quels compromis pourrais-je manquer ici?


2
Malgré les réponses actuelles, cela ressemble à une conception débile. «Soyez libéral dans ce que vous acceptez et conservateur dans ce que vous envoyez» et tout cela. C'est aussi complètement inutile. Je soumettrais certainement un rapport de bogue (fortement libellé) à Moinmoin. À tout le moins, ils devraient documenter et commenter clairement ce comportement peu intuitif.
Konrad Rudolph

Réponses:


33

Les balises de fin des péléments étaient facultatives en HTML et n'étaient nécessaires qu'en XHTML. Cependant, le brouillon HTML5 introduit un ensemble de conditions lorsque la pbalise de fin est réellement facultative:

La balise de fin d'un élément p peut être omise si l'élément p est immédiatement suivi d'une adresse, d'un article, d'un côté, d'un blockquote, dir, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header , hgroup, hr, menu, nav, ol, p, pre, section, table ou ul, element, ou s'il n'y a plus de contenu dans l'élément parent et que l'élément parent n'est pas un élément a.

Source: spécification HTML5

Cela dit, le seul argument que j'ai jamais entendu pour omettre les balises de fin des péléments est la taille du document. C'est à vous de décider si cela a du sens pour votre document ou non. Personnellement, j'ai tendance à inclure toutes les balises de fin facultatives, juste au cas où je ne répondrais pas aux exigences lorsque la balise de fin est facultative.


5
Les grands esprits pensent de la même façon, je suppose. :)
Robert Harvey

@RobertHarvey Vous gagnez ce tour, par 12 secondes ...
yannis

2
Un autre argument en faveur de l'omission des balises de fin: elles sont évidentes à partir de la structure du document, et lorsqu'elles sont mal utilisées, elles peuvent également introduire de faux espaces.
Jon Purdy

1
Pouvoir omettre les balises de fin était explicitement une fonctionnalité de conception de SGML, sur laquelle HTML était basé. Ce n'était pas non plus explicitement une fonctionnalité de XML, sur laquelle XHTML est basé.
Alan Shutko

4
Un argument que je vois souvent, c'est qu'il semble plus propre. En particulier dans le cas des <li>balises, les balises agissent davantage comme des puces.
DisgruntledGoat

16

La spécification W3C pour HTML5 stipule spécifiquement que:

La balise de fin d'un élément p peut être omise si l'élément p est immédiatement suivi d'une adresse, d'un article, d'un côté, d'un blockquote, dir, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header , hr, menu, nav, ol, p, pre, section, table ou ul, ou s'il n'y a plus de contenu dans l'élément parent et que l'élément parent n'est pas un élément a.

Donc, fondamentalement, la spécification a fourni de nombreuses façons d'éviter la complexité (grande ou petite) de la fermeture de la balise. Toute implémentation de navigateur conforme devrait tenir compte de ces exceptions.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.