tl;dr
Some widely used programs, which generate html, will only generate opening paragraph tags, and not closing ones, assuming that the browser will properly close paragraphs.
On the face of it, it seems to me that the assumption that browsers will properly close paragraphs is not correct. Is my interpretation correct? More generally, what tradeoffs are involved in this kind of decision?
Browsing through moinmoin source code, the following line of code caught my eye:
# We only open those tags and let the browser auto-close them:
_auto_closing_tags = set(['p'])
(source)
After reading throug the rest of the implementation, I’ve convinced myself that yes, indeed, when moinmoin generates html code for one of its pages, it will correctly generate paragraph open tags, where appropriate, while at the same time purposefully avoiding any of the paragraph close tags (despite being able to trivially do so).
For my specific, rather unusual, use case, this behaviour is not correct. I’m tempted to submit a bug report and/or change the behaviour. However, it looks like this design decision was thoughtfully made. I’m not well enough versed in the intricacies of the html standard, or the various browser implementations, to be able to tell if this is correct behaviour in general, and I have the feeling that my instinct to correct/change this behaviour might be misguided.
Is this code making a valid assumption about browser implementations? Is the generated html valid? More generally, what tradeoffs might I be missing here?
1
End tags for p elements were optional in HTML, and were only required in XHTML. However, the HTML5 draft introduces a set of conditions for when the p end tag is actually optional:
A p element’s end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, dir, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, menu, nav, ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is not an a element.
Source: HTML5 specification
That said, the only argument I’ve ever heard for omitting the end tags for p elements is document size. It’s completely up to you to decide if that makes sense for your document or not. Personally I tend to include all optional end tags, just in case I don’t meet the requirements for when the end tag is optional.
5
The W3C specification for HTML5 specifically states that:
A p element’s end tag may be omitted if the p element is immediately
followed by an address, article, aside, blockquote, dir, div, dl,
fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hr, menu, nav,
ol, p, pre, section, table, or ul element, or if there is no more
content in the parent element and the parent element is not an a
element.
So basically the spec has provided a lot of ways by which the complexity (large or small that it may be) of closing the tag can be avoided. Any conforming browser implementation would have to accommodate these exceptions.