[whatwg] P element's content model restrictions

[Benjamin Hawkes-Lewis]

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.