[RubyPinch]

> A p element's end tag may be omitted if the p element is immediately followed by block-ish element, or if there is no more content in the parent element.

> This doesn't apply if you are doing weird stuff in a non-block-ish element, or a media element, or a custom element.

is the easier way to think about it usually

[h1d]

It's really just better to keep a closing p tag, so you don't have to care about consequence when you edit that part later... Does not type </p> save anything? No.

[RubyPinch]

I honestly prefer it when editing

    <p>
        It naturally acts as a clean way to segment
        paragraphs of text
    <p>
        And most of the tag-closing rules are roughly
        matched with the rules of using p tags altogether.
    <p>
        e.g. you can't have a div within a paragraph, so
        closing or not closing, divs can only come after 
        paragraphs!.

[hellcow]

It actually saves at least 4 bytes per closing tag. On a larger webpage, that could easily add up to saving hundreds or thousands of bytes per request. That's a significant savings, especially for mobile.

[h1d]

gzip makes it insignificant.

I just took a sample page out of here which has bunch of p tags open and closed, gzipped the original and the one with </p> stripped, difference was 39 bytes.

https://en.wikipedia.org/wiki/C_(programming_language)

[emn13]

Ironically, if end tags were truly non-optional, html might actually compress better, because it would have less entropy (less choices). In practice, it would allow for a compression filter to represent the tree structure in a less redundant form with fewer corner cases to deal with (much like compressors do for binaries, for example).

[rhizome]

Thousands? Over 250 p tags on a page?