This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The syntax section says: "A p element's end tag may be omitted ... if there is no more content in the parent element." Which allows for: <ins><p></ins> <del><p></del> <math><mi><p></mi></math> <!--<svg><foreignobject><p></foreignobject></svg>--> ...all of which I think result in parse errors. It should say something like "... if there is no more content in the parent element and the parent element is not ins, del, or in the MathML <!--or SVG--> namespace." (Add <a> to that list when we allow blocks in <a>.)
I didn't want those to be parse errors. Can we fix that somehow?
Wait, why are they parse errors?
I guess because two browsers (Opera and Safari) agreed on what the DOM should look like. (IE creates a malformed tree, Firefox closes the P. Opera's rendering also doesn't match the DOM.) I'd be fine with the Firefox behavior for <ins><p></ins>x (while keeping the Safari behavior for <p><ins><p>) and using that for <mi>/<foreignobject> too.
No, I mean, where does the spec cause these to be parse errors? Which line is triggering the parse error?
Ah. I wasn't reading the spec, I just assumed that html5lib was correct. :-) It seems the spec says to first "Set node to the previous entry in the stack of open elements." and then generate implied end tags for the p, and so this isn't a parse error per spec and the above snippets don't parse into what I had expected. (I expected the P to not be closed.) However the spec disagrees with browsers for how to parse <foo><p>1</foo>2, but I guess we'll see whether this breaks anything...