[whatwg] <p> elements containing other block-level elements

[Ian Hickson]

On Thu, 7 Apr 2005, Lachlan Hunt wrote:
> 
> What is the use case for [allowing] tables to be nested inside <p>?

For instance:

   When you look at

      x | 1 | 2 |
     ---+---+---+
      1 | 1 | 2 |
     ---+---+---+
      2 | 2 | 4 |
     ---+---+---+

   ...it is clear that [bla bla bla].

I agree that it doesn't seem to make much sense to nest paragraphs inside 
those tables though.


> > I'm trying to work out exactly what the rules that describe the above 
> > actually are, but I'm interested in hearing whether people agree or 
> > disagree with my "good" and "bad" examples above. I'm especially 
> > interested in what use cases I may have missed (please don't say "I 
> > think this should be allowed" without giving a real-world example), 
> > and whether anyone thinks any of the cases I think should be allowed 
> > should not.
> 
> You missed <p><blockquote/></p>.

Oops, yep. Added.


> <blockcode> should probably be allowed too, though it doesn't seem to be 
> included in web apps.  Oh well, that's probably a discussion for another 
> thread anyway, if it hasn't already been discussed (I'll search the 
> archives later).

We haven't discussed it yet. I hadn't really thought about it but given:

   <pre><code> ... </code></pre>
   <blockcode> ... </blockcode>

...and given that the former would work in all existing UAs and the second 
wouldn't, and the former has the same semantics as the second, I don't see 
much of an advantage to the second.


> > Note that all of this would only be relevant to XHTML content (i.e. in 
> > an XML context), since in text/html HTML we are pretty much stuck with 
> > the existing parsing models which do things like close <p> elements 
> > upon hitting another block-level element.
> 
> It's a shame no browser actually reads the DTD, this wouldn't be a 
> problem if they did :-(.  This is one reason why HTML should be a true 
> SGML application, and why browsers should have been built to conform.

Yeah, well. In the words of Syndrome: "Too late. 15 years too late."


On Thu, 7 Apr 2005, Anne van Kesteren wrote:
>
> Ian Hickson wrote:
> > One thing that XHTML2 does which makes a lot of sense to me is allow nesting
> > of certain elements within <p> elements, as in:
> > 
> >    <p>
> >     For this recipe you need
> >     <ul>
> >      <li>an egg,</li>
> >      <li>flour, and</li>
> >      <li>butter.</li>
> >     </ul>
> >     Mix it all together and so forth.
> >    </p>
> 
> The problem is that you mix inline with block-level. Unless UL is 
> redefined to be inline level within P I don't think this is a good idea. 
> I like the idea of having either inline or block-level content.

The spec now has block-level, structured inline-level, and strictly 
inline-level concepts. I'm not overly fond of the names (better 
suggestions welcome), but I hope it addresses your concerns.


> >   * <pre> 
> 
> We have CODE and other nice inline elements for this.

I'll look at <pre> again when it comes to specifying it. I'm not really 
happy with its semantics myself either. There is a difference between 
<pre> (or <pre><code>) and <code>, though; the former is much more block- 
like than the latter. I feel that's somewhat important.


> That is indirectly nesting P elements, a bit ugly IMHO. It also doesn't 
> make sense.

Agreed.


> >   <ol>
> >    <li>
> >     <p>
> >      ...
> >      <ol>
> >       <li>
> >        ...
> 
> Why would you want a P element there?

It would probably be part of something bigger, as in:

   <ol>
    <li>
     <p>...</p>
     <p>...</p>
     <p>...</p>
     <p>
      ...
      <ol>
       <li>...


> >   <pre>
> >    <p>...</p>
> >    <p>...</p>
> >   </pre>
> 
> Ouch! Forbid this.

I probably agree with this, but I'm not 100% sure. What about <pre> 
blocks around e-mails:

   <pre>
    <p>Access via the DOM also affects styling.</p>

    <p>Also, if UAs have to parse it in the old way, what's the point?
    It's not increasing the semantics, since the UAs have to parse it the 
    old way.</p>
   </pre>

...or something. Then again, that does look pretty bad.


> >   <p>
> >    ...
> >    <pre>...</pre>
> >   </p>
> 
> Use case?

An inline example, as in:

   <p>
    An inline example, as in:
    <pre>
     <p>An inline example.</p>
    </pre>
    ...is one use case.
   </p>

...is one use case.

(Sorry.)


On Fri, 8 Apr 2005, Michael Gratton wrote:
> 
> As was pointed out elsewhere on this thread (list?), existing UAs would 
> implicitly close any outer block elements upon encountering a nested 
> block element.

In text/html, yeah. I propose we don't change that for HTML5 UAs. It would 
only be in XHTML documents that you could use these new features (that and 
by direct DOM manipulation).


On Fri, 8 Apr 2005, Anne van Kesteren wrote:
> 
> You removed it now but I think that the 'XML content model' approach 
> made it quite obvious that is not the HTML content model.

I'll be putting that back in due course. I want to first get the basic 
language done before starting to add the HTML vs XML exceptions. :-)


On Fri, 8 Apr 2005, Lachlan Hunt wrote:
> > 
> > The question is whether:
> > 
> >  a) We don't allow any of this.
> 
> I don't think progress should be held up any more than it already is by 
> broken browsers, so let's not let a limitation with HTML affect an XHTML 
> implementation.

Agreed.


> >  b) We allow it in XML and the DOM but disallow it in the HTML 
> > serialisation
> 
> Yes, this makes the most sense to me.

Cool, it seems we are in agreement then.


> Absolutely!  Given the incredibly broken SGML/HTML implementations that 
> will never get any better, Migrating to XML is certainly the best way to 
> actually progress into the future.  I'm sure no-one wants to be stuck 
> with HTML forever, which is really more of a lost-cause when it comes to 
> any real enhancements.

I think we'll probably be "stuck" with HTML for a very long time -- at 
least as long as it takes for XML to have a variant created that has 
well-defined error handling rules other than the author-hostile "abort 
processing immediately".


> I don't think the spec should limit nested content too much because, as 
> is shown by the <p><blockquote><p/></blockquote></p> example, there are 
> valid reasons to nest paragraphs, and possibly others we haven't thought 
> of.

Agreed. I've made the spec not restrict the content models per se, just 
say "this element can contain this category of elements" and made sure the 
elements are in the right categories.


> Also, as history has shown, HTML4 never thought lists within paragraphs 
> would be needed, though they are now allowed.  By placing too much 
> restriction on the content models, we risk locking out legitimate 
> use-cases which we haven't thought of, but which authors may find in the 
> future.  I'm not saying we should just allow anything within anything, 
> but we should be careful about being too restrictive.

I agree. We should be careful not to allow too much too, though -- it's 
easier to allow new things previously disallowed than remove old things 
previously allowed.


On Fri, 8 Apr 2005, Henri Sivonen wrote:
> > 
> > (In fact you need special code for <style> in general, since it's 
> > PCDATA in XHTML and CDATA in HTML.)
> 
> I know. I intend to deal with <style> and <script> later--just for 
> completeness. Currently, I am dodging the issue by avoiding embedded 
> styles and scripts.

I would suggest that in that case the solution would be to avoid nesting 
elements in this way as well.


> > Is catching <ul>s inside <p>s something that crosses the line?
> 
> It changes assumptions rather significantly if you need to know at the 
> input stage what output flavor is going to be used.
> 
> I see the option are:
> a) Banning XHTML divergence for everyone.
> b) Behaving as if a) was the case and barfing at XHTML that cannot be 
> serialized as HTML.
> c) Bending over backwards in order to track whether a given piece of 
> data can be serialized as HTML and whether there is a future need for a 
> given piece of data to be serialized as HTML.
> 
> Option a) doesn't seem popular and implementing c) would be a pain, 
> which seems to leave b) for those who serialize as HTML. Of course, the 
> reason why one would want to serialize as HTML is IE (and Lynx).

Agreed. Is option b acceptable to you?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'