- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Tue, 29 May 2007 07:37:06 +0100
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.
Received on Monday, 28 May 2007 23:37:06 UTC