[Standards] Proposed XMPP Extension: Styling

Jonas Wielicki jonas at wielicki.name
Wed Nov 8 11:15:24 UTC 2017


On Mittwoch, 8. November 2017 11:58:57 CET Goffi wrote:
> Le mercredi 8 novembre 2017, 11:18:51 CET Jonas Wielicki a écrit :
> > On Mittwoch, 8. November 2017 10:58:06 CET Goffi wrote:
> > 
> > We’re having a nice, civil discussion in xsf@ right now about this, let me
> > summarize my current viewpoint on this (as author of the Message Markup
> > proposal):[SNIP]
> 
> Hi Jonas,
> 
> unfortunately I'm too busy now to follow that. The reason why I think style
> is not needed anymore is:
> 
> - if a client want to do styling, he knows it, and it just have to:
> 	* use markup element as specified in https://xmpp.org/extensions/inbox/
> markup.html
> 	* remove, or eventually keep the markup at its discretion

Styling is very useful as it essentially specifies a markup language. Thus we 
get consistent parsing across clients -- at least as long as Styling isn’t 
modified. As a bonus, this markup language codifies what is being typed into 
(presumably) millions of text boxes right now. Which is good (efficiency is a 
product of familiarity).


> - we can have an extension to markup to specify style-like syntax for markup
> characteres we can safely remove, as mentionned in other thread. The syntax
> can be exactly the one of style, this would not be an issue.

Exactly. I suggest we do that.


> - at the end, using markup with a style-like syntax is exactly like style at
> the only difference that a client doing that must add <markup> element to
> specify were the styling is. 

This is what is going to happen, plus a hint that the body is also Styling 
markup. Which is good for entities which only support that for whatever 
reason.


> I would rather not have "*" and other "`" in
> the <body>, but if it makes everybody happy it may be OK.

I think those are needed to have a proper plain-text fallback in any case. I 
am contemplating adding very precise rules for adding those characters to 
<body/> when creating a <markup/> message. In addition, I plan to make those 
rulse compatible to Styling (i.e. so that Styling + markup messages are 
valid). This has the advantage that human users of clients not supporting 
Markup can better interpret received messages (Plain-text fallback).


> If we keep style with an attribute in addition to markup (and XHTML-IM at
> least for a while), we are just multiplying ways to do markup, and make the
> message parsing more complicated (and bug prone).

I don’t see any bug prone-ity here. In my client, I’ll choose whatever format 
I can support best (which would be something like markup > XHTML-IM > Styling) 
on the receiving side. On the sending side, I’d default to Styling (unless 
turned off by the user *or* if explicit markup has been used) + Markup. If a 
user wants to remove Styling-based markup from the message, they can do so 
with last message correction with a simple "Remove markup" button.


> The only reason I would see to keep style is for e2e encryption because
> OMEMO doesn't handle anything else that <body>, and this is a bad reason :
> OMEMO needs to be fixed, and markup doesn't prevent using it.

We agree that OMEMO needs fixing in that regard. It isn’t a blocker for 
<markup/> in non-OMEMO conversations though.


kind regards,
Jonas
-------------- 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/20171108/6fca76ea/attachment.sig>


More information about the Standards mailing list