5836 2008-07-06 19:36:55 +0000 Syntax section allows <ins><p></ins> 2010-10-04 14:47:58 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified All All CLOSED INVALID P3 normal --- 1 zcorpan ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 21072 0 zcorpan 2008-07-06 19:36:55 +0000 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>  ...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  namespace." (Add <a> to that list when we allow blocks in <a>.) 21073 1 ian 2008-07-06 22:05:01 +0000 I didn't want those to be parse errors. Can we fix that somehow? 21074 2 ian 2008-07-06 22:29:44 +0000 Wait, why are they parse errors? 21077 3 zcorpan 2008-07-06 23:29:48 +0000 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. 21078 4 ian 2008-07-06 23:36:21 +0000 No, I mean, where does the spec cause these to be parse errors? Which line is triggering the parse error? 21079 5 zcorpan 2008-07-07 00:34:20 +0000 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...