Alex Jones wrote:
By the way, how the sending client knows in is an emoticon? Many users I
know just type them, not select from list.
That's an application issue that can be tackled. In any event, rather
the sender decide than the receiver.
Yes. The sending user will see how her client interpreted what she
typed, and can therefore control what the receiving user will see before
clicking <SEND>.
Alex Jones wrote:
On Wed, 2007-08-08 at 13:21 +0100, Ian Paterson wrote:
Mridul Muralidharan wrote:
If we just add another tag to explicitly mark emoticons - and remove
the implicit rendering completely - then Alex's baseline requirements
should be done with IM-XHTML itself ?
Yes. This would be backward compatible too since, IIRC, XHTML parsers
should ignore tags they don't understand (and the tag would be qualified
by a namespace other than 'http://www.w3.org/1999/xhtml' anyway).
I feel it shouldn't be a part of XHTML-IM though. I think there is a
need to use icons that is independent of the need to use even the most
minimal, valid support of XHTML-IM.
Well, RFC 3921 states that "the <body/> element MUST NOT contain mixed
content".
And I agree with Michal that we should avoid including three copies of
the message in each stanza. So it seems that the only place for the new
emoticon tags is inside the XHTML-IM (under a different namespace).
Furthermore, it would be complicated to write the code to display both
XHTML and emoticon elements if they are kept separate. Whereas it is
trivial to write the code to ignore the one or the other if they are merged.
- Ian
