[Standards] XEP-0394: too weak to replace XEP-0071

Jonas Wielicki jonas at wielicki.name
Mon Mar 19 08:00:45 UTC 2018

On Freitag, 16. März 2018 12:11:31 CET Kozlov Konstantin wrote:
> Yes. CSS is really a hard part. But we don't need full support of CSS for IM
> message styling. Maybe it's better to simplify XEP by specifying a small
> subset of CSS rules needs to be implemented, as it was done with XHTML tag
> subset?

XEP-0071 already did that. This doesn’t save an application from having to 
parse all inline CSS and sanitize it, which is the hard part.

> But I don't like the idea of sacrificing ability to compose rich
> text in WYSIWYG editor in favour to "accessibility". Yes, anyone is annoyed
> when interlocutor sends messages abusing rich text formatting. But you can
> abuse any good feature. WYSIWYG is always preferred by end user.

This is true, and in general, '394 does not prevent you from creating a 
WYSIWYG-style editor. If you are concerned about the weak definition of 
"emphasis", I think it would be fine to say it SHOULD be italic/bold (weak vs. 
strong emphasis respectively).

This will allow WYSIWYG to work in *most* cases, and where it does not 
represent exaclty "what you get", there will be good reasons for that.

> Especially
> when it comes to messaging. Especially on mobile devices, where you need to
> switch between different keyboards every time you want to type special
> characters like ',~,`{},_,* and so on.

This was never and will never be a necessity with '394. A client *may* choose 
to offer this as a way to input text, because many are used to this from other 
(albeit probably non-mobile-centric) messengers.

> Yes, I'll be annoyed receiving a lot
> of messages with strange fonts, different font sizes and colors. But for
> many years of exploiting XHTML-IM enabled client I never was in such
> situation, 'cause most of the people in this world are adequate. 

I am in this situation every other day because stupid clients allow people to 
paste XHTML from websites. Websites tend to default to black-on-white. My 
client is white-on-black. Now I get black on black. Neat!

This is of course primarily an issue with my receiving client, which should 
prevent this from happening; except that it can’t know the background color 
because it runs in a terminal. It would have to set the background color, 
which has other portability issues in itself (i.e. it would also have to set 
the foreground color and thus ignore all the theming settings I do in my 

On the other hand, the XEP-0392 (Consistent Color Generation) implementation I 
wrote for that client works just fine; which is why I’m confident that 
XEP-0394 using XEP-0392 hues would be a great middle-way to this.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180319/4af88183/attachment.sig>

More information about the Standards mailing list