[whatwg] P element's content model restrictions
Leif Halvard Silli
lhs at malform.no
Mon May 28 19:07:11 PDT 2007
The subsection 22.214.171.124. «Restrictions on content models» puts restricions «for historical reasons» on the content model of amongst others, the P element (my understanding is that the restrictions are only valid for the HTML5, but not for XHTML5 - please, correct me if I am wrong):
A p element must not contain blockquote, dl, menu, ol, pre,
table, or ul elements, even though these elements are technically
allowed inside p elements according to the content models described
in this specification. (In fact, if one of those elements is put
inside a p element in the markup, it will instead imply a p element
end tag before it.)
I'd like to question these restricions. I think that at the very least, TABLE should be allowed inside the P element. The reason is that MSIE (I tested version 6 and 7) accept TABLE in P, regardless of whether it is in Quirks-Mode or in Standards-Mode. Even Firefox-Opera-Safari (FirOpSa) allow TABLE inside P - allthough they only do so when in Quirks-Mode. When in standards mode, FirOpSa behave according to the HTML5 restriction quoted above. I have a test page here, where the DOCTYPE get MSIE into standards mode, and FirOpSa into Quirks-Mode, and with two TABLE elements in the second P-element of that page: <http://www.malform.no/prov/content-model/index.html>.
In my view, it isn't desirable to limit the containment of TABLE inside P to quirks-mode (and XML ...). Quirks-Mode should only deal with CSS quirks. This is a «content model quirk».
As the test page also shows, it would not be _that_ simple to allow BLOCKQUOTE, DL, MENU, PRE or UL in today's browsers. However, if you stuff any of those elements in a SPAN element, then they become more digestible - for Firefox and Safari and little brother iCab (but not for Opera or MSIE). (And when reading section 3.12.18. «The span element», SPAN is said to be allowed to contain «Otherwise: any inline-level content», i.e. structured inline-level content as well – thus stuffing e.g. UL in SPAN seems to be in line with the content-model. It is unclear to me whether the restrictions in 126.96.36.199 is meant to also count for SPAN inside a P - but I assume they are.)
I'd also like to mention that both Firefox, Opera and Safari allow the restricted elements, as well as P itself, to become nested inside a P provided you stuff them inside a OBJECT. (See the mentioned test page). Whether this is allowed according to HTML401, is unclear to me. But HTML401 gives many code examples, using P without closing tag (thus sometimes open for interpretatations) where P inside OBJECT inside P is used. And it is at least not forbidden. And the HTML validator accepts it. Note that FirOpSa _nest_ P inside P this way: You will see a P with margin, padding and border inside its «parent P». MSIE does not allow P inside OBJECT though.
The MAP element is also worth mentioning in this context. It may appear inside P. And it may also contain block level elements. Thus via MAP a P-element may contain another P-element. It is my experience that those browsers that nest P inside P via the OBJECT (I am thinking about when the embedded content of OBJECT is unavailable), does not handle P inside MAP inside P. (To see if User Agents does not handle P inside MAP inside P or P inside OBJECT inside P, one must apply BORDER, MARGING and or PADDING, and perhaps background color - then you will see how it falls apart. Opera, for instance, does not handle P inside MAP inside P.)
Anyway, the whole thing about what P may or may not contain in HTML, is much more blurred than a fast reference to «historical reasons» can tell. Hence it would be better to try to un-restrict the content-model of P as much as possible. Because if HTML5 will continue to apply these restricitons on P, then authors must continue to work with paragraphs in HTML in quite unintuitive ways.
leif halvard silli
More information about the whatwg