[whatwg] <p> elements containing other block-level elements
Lachlan Hunt
lachlan.hunt at lachy.id.au
Mon Apr 11 19:02:06 PDT 2005
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
More information about the whatwg
mailing list