Using markdown for text formatting is a bad idea. Markdown is used as a simple means to give a semi-rich text formating where complex WISIWYG editors can't be used. Like, webpage contents editing in many CMSs. However, user always knows that if he styles text using markdown, it'll always be presented in rich text form. This isn't the case with XMPP messengers, where user typically has just one field to enter message text. App has no way of knowing if user intended to be rich format text or not. Also, app has no way of knowing if it has to provide a plaintext version of message, and markdown version.
It will likely result in app treating all messages as 'markdown' messages, and any unsupporting clients would get messages with ## --- etc. It'll also result in unwanted formatting if users will send each other portions of code or config files, commented out lines would be presented as headers, etc. It can be avoided if sending user will get some form of control whether they want to have it processed with markdown or not (like a switch), but it'll complicate UX, and switching from plaintext to markdown is generally worse than switching from plaintext to WISIWYG interface employing some kind of rich editor to compose messages (like Gmail does, for example). 2018-03-15 20:09 GMT+05:00 Philipp Hörist <[email protected]>: > Why would we make the body 393 compatible? > > Is it too much to ask from developer to parse a markup tag and style the > string accordingly?! > > we talk about max 5 lines of code here > > start, end = getTag('emphasis').getAttrs() > string.addStyle('emphasis', start, end) > > take this times 5 for the 5 elements 393 supports > > thats an approximation > <https://dict.leo.org/englisch-deutsch/approximation> but i dont need > much more in GTK/Python3 > > So i dont really see the reason why i should add some backup body for > clients who dont support that. > > 2018-03-15 15:46 GMT+01:00 Kozlov Konstantin <[email protected]>: > >> >> >> 15.03.2018, 16:31, "Jonas Wielicki" <[email protected]>: >> >> Okay, so since I’m not going to get around to updating '394 this month and >> there’s considerable interest, I’ll write down what I have in mind: >> >> * Emphasis, Strong emphasis, inline-preformatted (code) >> * Enumerations >> * Itemized lists >> * Headings (two or three levels) >> * Paragraphs >> * XEP-0392-based colors (i.e. you only give a hue and the remainder is >> handled >> by the recipient) >> * Code blocks with annotation of the language for optional receiver-side >> highlighting >> * Maybe inline images >> >> It sounds promising. I just wonder why no links and no font customization? >> >> Now there has been a lot of discussion around how to make this degrade >> gracefully. I’m thinking of the following: >> >> Each markup annotation has a mandatory pre- and postfix in the body which >> is >> stripped once the markup is applied. That works like this (just a rough >> outline, don’t take the syntax for literal): >> >> <body>This is the *new* markup.</body> >> <markup> >> <emphasis start="12" end="17"/> >> </markup> >> >> Now <emphasis/> would be defined so that the selected range of <body/> >> MUST >> start with "*" and MUST end with "*". If-and-only-if (iff) that is the >> case, >> the prefix and postfix is removed and the text is displayed with emphasis >> applied on the word "new". >> >> This is complex, and will not get less complex with more complex >> constructs >> like enumerations. >> >> The reason for this complexity is that it allows a '393-compatible <body/> >> message, and also in general a good human-readable representation in >> clients >> which do not support it (if we chose the requirements well), while at the >> same >> time not allowing to "delete" arbitrary characters for some readers (it >> has >> been pointed out that this type of discrepancy can lead to problems). >> >> That idea is really interesting. An attempt to add compatibility to those >> two XEP's. >> But implementation <emphasis/> element like this without additional >> statements implies support of XEP-0393. >> IMHO it should be stated, that <emphasis/> element should be allowed only >> if other party explicitly supports not only XEP-0394, but also XEP-0393. >> Otherwise, it would be impossible to implement XEP-0394 without >> implementing XEP-0393, and XEP-0394 will be just an addition to XEP-0393. >> >> With my best regards, >> Konstantin >> >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> _______________________________________________ >> >> > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > > -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
