[standards-jig] message formatting (XHTML IM)

Sebastiaan Deckers cbas at screaming3d.com
Thu Jun 19 04:23:43 UTC 2003

Hi all,

I only took a quick look at Textile but it seems more a user interface 
specification (text based markup control) than a markup specification.
It would be trivial for clients to allow users to type Textile, and 
convert it on the fly into XHTML+CSS.
Just like users today type "/me ..." which is then converted to some 
coloured/indented string in the graphical interface.  Except that 
Textile could be converted at either end (sender or recipient) into XHTML.

As for my implementation notes on XHTML  I gave it a go some months back 
but found too many incompatibilities between transports and other clients.
There was even a client (which shall remain nameless) which passed on 
any <script> elements or onclick="" attributes to the Internet Explorer 
control used to display formatted text.  This was obviously a *major* 
security risk.  Clients need to implement an XHTML filter to make sure 
no hidden scripts are launched.
Another issue is that of images being loaded and used to track user 
activity, as is often done with spam emails.  Another filter is required 
to prevent this from happening.
If clients want to send images they should do that in a seperate 
namespace.  The HTML-email backlash proves this.  (Is anyone working on 
such a JEP?)

I fear most users will not appreciate this text-formatting feature until 
the XHTML implementation differences between clients and transports are 
As an in-between solution I might implement the *bold* /italic/ 
_underscore_ syntax, which fails more gracefully than unexpected XHTML 


Dave Smith wrote:

>On this thread of standardizing on XHTML...
>If we're only interested in the most basic of markup (bold, italics, etc.)
>perhaps we should simply consider standardizing on a convention such as
>Textile (http://www.textism.com/tools/textile/index.html). Similar in
>scope to the widely used "/me" convention, we could just embed the markup
>directly in the message body, since it's still "human-friendly".
>It's a low barrier to entry for client writers (if you support emoticons,
>you've already got the infrastructure to support this) and adds a lot of
>value, imho.

More information about the Standards mailing list