The subsection 8.1.2.5. «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 8.1.2.5 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
