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

Ненахов Андрей andrew.nenakhov at redsolution.ru
Thu Mar 15 15:29:53 UTC 2018


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 <philipp at hoerist.com>:

> 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 <yagiza at yandex.ru>:
>
>>
>>
>> 15.03.2018, 16:31, "Jonas Wielicki" <jonas at wielicki.name>:
>>
>> 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: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>>
>>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
>


-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180315/1ed0a209/attachment-0001.html>


More information about the Standards mailing list