It is indeed absurd for a /document/ markup language not to be able to
represent ordinary paragraphs. If we introduced a <para> element as an
alternative container, would today's browsers treat that as block or inline?
--
Benjamin Hawkes-Lewis
Leif Halvard Silli wrote:
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.
