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

[Henri Sivonen]

On Apr 8, 2005, at 17:11, Ian Hickson wrote:

> On Fri, 8 Apr 2005, Henri Sivonen wrote:
>> Ian Hickson wrote:
>>> At the end of the day this would just be saying "in XML you can also
>>> do this". Avoiding those options for people who serialise to both XML
>>> and HTML is relatively easy, just like avoiding xml:base and MathML.
>>
>> Detecting stuff in non-XHTML namespaces is significantly easier than
>> detecting incompatible use of XHTML elements.
>
> Very true. But you have to do the checking anyway.

The issue is how and at what time.

> Say someone wrote this
> (non-conforming) markup:
>
>    ...
>    <p>
>     <input> Test </input>
>    </p>
>    ...
>
> You wouldn't be able to serialise it to HTML.

No, but that wouldn't be conforming as the XHTML flavor, either. 
Therefore, that kind of content should not enter a CMS regardless of 
serialization.

> Or this:
>
>    <style>
>     <em> { color: red; }
>    </style>
>
> Again, you need special serialisation code for that.

Again, that does not make sense in either flavor.

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

> Come to think of it, you also need special processing for <script> --
> processing that actually changes the script, since for legacy UAs you 
> need
> the non-namespaced methods but in XML you have to use the namespaced 
> ones.

I would prefer to say that scripts ought to be external and their 
writers more aware of HTML vs. XHTML issues that casual content 
writers.

> So I don't think the situation is as clear cut as all that.
>
> 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).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/