- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 11 Apr 2005 16:50:17 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 11 April 2005 09:50:17 UTC