[JDEV] Emoticons: guidelines

[Dave]

Reply inline:

 - Dave

Note: I'm in almost complete agreement, so you may not want to bother
reading this message if you're short on time.

Dave Turner wrote:
> 
> On Mon, Apr 22, 2002 at 04:21:22PM -0400, Dave wrote:
> > That was my other original idea (take a peek at my first post on this
> > subject, a few days ago).  However, the sender may want a little more
> > control over the interpretation of his message, and having the receiving
> > client decide those regexps takes that control away from the sender
> 
> That was my intention.  I agreed with your initial post.  I actually
> prefer the way that AIM, for example, transmits it's emoticons as
> commonly recognised ascii and then the receiver, if it supports it,
> interprets them and inlays the images.
The problem is that many of the emoticons that people want didn't grow up
in the email universe, so they're just images - the only "sensible ASCII"
translation would be a word in some language describing the meaning of
the image.

> 
> I'd rather define how I look at the data coming to me than the sender.
> The sender should describe WHAT the data is not HOW it should be viewed.
That's a fundamental principle of XML (and _was_ a fundamental principle
of HTML, until Netscape and Microsoft got their hands on it).

> 
> 
> > That whole question is moot if you're using an existing standard (like
> > HTML IMG tags), rather than stewing your own kludge: web browsers are
> 
> At least with the IMG tag I guess you can use the 'alt' attribute to give
> a text alternative which I could settle for.
I tend to like that solution, but I can read English, so the
ALT attribute makes sense to me.  Jabber still lacks built-in
internationalization support, so anything we do will have to include
its own internationalization support - else, we'll have the whole
international community trying to lynch us ;-)

> 
> 
> If the general aim is to format the output at the receiver end, how about
> XSLT?  Then the receiver has ultimate control over formatting, the data
> that is transmitted is suitably marked up to describe the content, and the
> sender can recommend a particular display format for the data.
That can be abused too easily.  At least HTML is more mature, so working
around abuse is easier.

> 
> 
> -- 
> Dave Turner
> http://figroll.com/
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>