[Standards] Proposed XMPP Extension: Styling
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/
> * 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards