XHTML allows clients to support simple styled text (colors and fonts) or full blown xhtml support. It is a standard alternate body namespace, to be used if supported. A simple example: <message><body>hi</body><html xmlns="http://www.w3.org/1999/xhtml"><body><h1>hi</h1></body></html></message>.
All of the textual content must always be represented as best as possible in the normal body for non-supporting clients or alternate display. If after sending xhtml with a thread in a conversation, and the thread being returned without an xhtml alternate body, the client should stop sending the xhtml (because a user choosing to use/display xhtml would return the thread in the next message and use xhtml). If the other client returns a browse request and doesn't include the xhtml namespace, it should default to off for that user, and vice-versa if included. This detection logic isn't required, but is highly suggested.
Nothing is really "required" in any sense, but if you would like to claim full conformance with this document, you must follow everything marked required, and should do some of the recommended stuff... required: <html xmlns="http://www.w3.org/1999/xhtml"> - must be the root element <body> - must be inside <html> <blockquote> - indent or italicize or somehow indicate that this text is a quote, but a large one, usually a paragraph or more <br/> - Clients should recognize that this is /n, and should be used instead of /n within the <html> portion of <message> <div> - at least understand that this divides into paragraphs. Basic support for the various align types would be nice <em> - This generally means italics <h1> through <h6> - The general headings, h1 is usually displayed with largest font size. Client should also understand that a /n is implied after a heading <p> - Client should understand this is a paragraph, and be sure to end with a </p> <q> - At absolute least, translate <q> to " and </q> to ", so things will appear in quotes. A proper client will also understand nested quoting <strong> - Most clients should recognize this as bold <a> - Clients should recognize at least http:// links (should they support jabber: as meaning a jabber user?), with optional support for mailto:. Relative links should be supported at the client's discresion optional, but recommended: <img> - If the image is pointing somewhere that the client can find it, feel free to display it. This might be useful for clients which wish to be more graphical - they can ship with standard images, and somehow the UI can allow users to select them and display to each other. It is recommended that clients be able to display the alt text for images. (Not necessarily the images themselves) <code> - this is used to designate a fragment of computer code - perhaps make this in a fixed font. It would be nice to see computer code exchanged with things like this instead of with quotations around it <ul> - Understand that this means text should be indented, and that its children, <li> are unordered (be sure to close the <li>'s) <ol> - Understand that this means text should be indented, and that its children, <li>, are ordered, usually this means with numbers, optional support for type numbering styles optional: <address> - If you want to do something special to an address <abbr> and <acronym> - if you wish to expand the title's of these on mouseover <cite> - "Contains a citation or a reference to other sources. " <dfn> - "Indicates that this is the defining instance of the enclosed term. " <kbd> - "Indicates text to be entered by the user." <pre> - pre-formatted text. If possible, do not wrap text within <pre>, as it should have its own wrapping <samp> - "Designates sample output from programs, scripts, etc." <var> - "Indicates an instance of a variable or program argument." <dl> and its buddies <dt> and <dd> - these are used for definition lists. Not that much more useful than <ul> and <ol>... not needed: <form> <input> <label> <select> <option> <textarea> - None of the input types or forms are needed. <table> <caption> <td> <th> <tr> - Most clients will not render tables properly, and they aren't worth the effort for an IM system <title> - This should not supercede the <message><subject> <head> - There is nothing within <head> which is needed <span> - There is no need when we don't support styles <meta> - If your client does have a good use for this, feel free <link> - Style sheets are not supported, they are too difficult <base> - absolutely no need
Styles are very important for message formatting, below are the required style="" values. Required: font-size color background-color Optional, but reccomended: text-decoration font-family Optional: text-align background-image
An example of absolute minimal support, requiring only the parsing of 3 CSS attributes on any element: <message> <body>hi</body> <html xmlns="http://www.w3.org/1999/xhtml"> <body style="color:red;background-color:green;font-size:large">hi</body> </html> </message>
Many clients have the ability to display or edit RTF in a widget somewhere, it would be nice if someone could contribute some minimal psudeo-code that would do the mapping between the above xhtml and rtf in both directions.