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

[Lachlan Hunt]

Ian Hickson wrote:
>><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>

To use <pre><code> like <blockcode>, one would have to style it with

   pre>code:only-child { display: block; }

Although, there is a very small use case that would make <pre><code> 
unusable for that purpose.  eg. in a marked up e-mail (or other plain 
text document), one may use <code> to marup code samples.  But when 
there is only one occurance of code in the whole document surrounded 
only by plain text and no other elements then :only-child would still 
match it, causing a potentially undesired effect.  Though, the chances 
of that happening are slim and probably not worth worrying about.

> ...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.

You could introduce <blockcode> as an XML only element, but then I guess 
there's not much stopping me from using <xhtml2:blockcode> instead.

>>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."

hehe. :-)  That's one reason why I now consider HTML to be a dying 
langauge and only being retained for backwards compatibility where XHTML 
support is unavailable.

>>> 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.

Wow, really!?  This must be a first. :-)

> 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 understand what's wrong with the XML error handling.  I think 
it's great because errors should be caught and handled during the 
authoring process and by the CMS, which XML essentially forces.  I don't 
think user agents should have to gracefully handle errors when it's 
trivial for authors to fix them.  Hopefully, one day CMSs will be built 
as real XML tools, and people will stop complaining about accidental 
errors causing a catastrophy.

The history of HTML has shown us that unobvious errors simply don't get 
fixed because many authors are too lazy to even bother checking, and 
many are even lazier to fix things when they do.  I've lost count of the 
number of posts to www-validator stating something like:

   "I think the validator should ignore X... I don't know how/want
    to fix it...  It works, so it is not invalid... The validator is
    wrong/broken."

If XML were to allow more graceful error handling, I see nothing but the 
possibility of history repeating all over again.

>>I don't think the spec should limit nested content too much because...
> 
> Agreed.

OMG!  Twice in the same e-mail!  What are the odds of that? :-)

> 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.

That seems like the most appropriate way to handle it.

-- 
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/     Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox