This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5836 - Syntax section allows <ins><p></ins>
Summary: Syntax section allows <ins><p></ins>
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2008-07-06 19:36 UTC by Simon Pieters
Modified: 2010-10-04 14:47 UTC (History)
3 users (show)

See Also:


Description Simon Pieters 2008-07-06 19:36:55 UTC
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:


...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>.)
Comment 1 Ian 'Hixie' Hickson 2008-07-06 22:05:01 UTC
I didn't want those to be parse errors. Can we fix that somehow?
Comment 2 Ian 'Hixie' Hickson 2008-07-06 22:29:44 UTC
Wait, why are they parse errors?
Comment 3 Simon Pieters 2008-07-06 23:29:48 UTC
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.
Comment 4 Ian 'Hixie' Hickson 2008-07-06 23:36:21 UTC
No, I mean, where does the spec cause these to be parse errors? Which line is triggering the parse error?
Comment 5 Simon Pieters 2008-07-07 00:34:20 UTC
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...