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

Henri Sivonen hsivonen at iki.fi
Sat May 7 11:36:31 PDT 2005

On Apr 11, 2005, at 19:50, Ian Hickson wrote:

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

I'm not a big fan of <pre>. In fact, I stay away from it and use 
<p><code>...</code></p> with no-break spaces for code snippets. For 
mail archives, I suggest supporting format=flowed, which means <pre> 
should not be involved.

> On Fri, 8 Apr 2005, Henri Sivonen wrote:
>> 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?

I suppose that realistically it has to be, because enforcing a) doesn't 
look like a realistic option. :-/

It would help if WHAT WG published a RELAX NG schema for the 
text/html-compatible subset of the XHTML flavor. That would make 
appropriate barfing easier. It would also facilitate the implementation 
of text/html flavor conformance checkers.

Henri Sivonen
hsivonen at iki.fi

More information about the whatwg mailing list