[standards-jig] message formatting (XHTML IM)
cbas at screaming3d.com
Thu Jun 19 04:23:43 UTC 2003
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
More information about the Standards