[Standards-JIG] XHTML further simplification

Byron Ellacott bje at apnic.net
Tue Sep 21 02:47:09 UTC 2004

Ian Paterson wrote:
> IMHO JEP-0071 may be simplified further. The changes below would all make
> implementation easier without reducing functionality.

> 1. The Text Module Profile should not include the <div/> element. For IM
> purposes <p/> is almost identical. The difference being that <p/> is more
> simple to implement because it does not allow the nesting of blocks. For
> example:
> <p>Nested paragraphs<p>like this one</p>are NOT allowed.</p>

This is true.  Allowing nested blocks means renderers will need to have 
a basic understanding of XHTML layout.

> 2. The Text Module Profile should not include the <br/> element. The two
> examples below render identically with any combination of the Recommended
> Style Properties:
> <p>Line one<br/>Line two</p>
> <p>Line one</p><p>Line two</p>

Semantically, they are different things.  If you follow the CSS1 spec 
for your paragraph layouts, including the sample HTML2.0 stylesheet, you 
will not have any margins or padding between paragraphs.  If, however, 
you use an HTML4.0 stylesheet, such as the CSS1 properties from the 
CSS2.1 default stylesheet, you will.  If you don't use CSS to lay out 
your paragraphs at all, or don't use either default stylesheet, it's not 

In other words, you cannot rely on this being true, because it's only 
true in a limited and probably not very common set of circumstances.

You also cannot duplicate <br/><br/> with <p/> elements, since an empty 
<p/> element should be ignored, according to the HTML4.01 spec, upon 
which the XHTML1 specs are built.

Further, closing a <p/> element and opening a new one will reset style 
information, while a <br/> element will not.

> 3. Whitespace should not be preserved (see Business Rule 7) since this is
> NOT consistent with standard XHTML rendering. The sending client should
> always use <p/> elements to indicate line breaks. It may replace multiple
> spaces in user input with multiple non-breaking spaces ( ), or use the
> CSS padding-left property. For examples:
> <p>Name:   Macbeth</p>
> <p>Name:<span style="padding-left:2em">Macbeth</span></p>

In part, I agree with you: the way this is specified is not particularly 
useful.  Since the JEP only recommends this behaviour, a sending agent 
cannot be sure that whitespace will be preserved, and thus to get the 
intended effect will need to use non-breaking spaces and <br/> elements.

On the other hand, a possibly better solution would be to provide a 
default stylesheet for XHTML-IM messages, including all the appropriate 
CSS1 (or CSS2.1) properties to render "as expected."  Implementations 
using a CSS renderer can then apply this stylesheet, while 
implementations not using a CSS renderer can use the stylesheet as a 

This stylesheet could then include a "white-space: pre" property, if so 
desired, as well as margin-{top, bottom} settings for <p/> elements.

> 4. <img/> width/height should be REQUIRED not just RECOMMENDED since:
> - "It gives the receiving application hints as to whether the image is too
> big to fit into the current interface."
> - The message can be displayed in the correct layout (with an image
> placeholder) before the image file has finished being downloaded.
> - Clients may decide to avoid downloading very large images.

This puts an onus on the sending program to discover an image's 
width/height.  A receiving program with limited screen space may choose 
to scale an image to a fixed size should it strictly require knowing an 
image's dimensions in advance.  A sending program may not necessarily 
have the ability to establish image dimensions (eg, a URL that is not 
fetchable from the sending program, or where that image's dimensions 
change over time.)


More information about the Standards mailing list