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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
