Hi, On 09.01.22 21:50, Dave Cridland wrote: > I'd still argue that it's a bad idea these days, even if Matrix haven't > learned from the trouble it's caused in email. Most other proprietary > messaging apps just have one form, the only reason email (and us, and > Matrix) went for alternatives is because of an existing deployed base > that only understood plaintext. This causes not only the problem of > messages having potentially wildly different meanings between the > alternatives, but also you can never get rid of the compatibility layer.
I do not agree here at all. The "compatibility layer" is not only for older clients that don't implement the latest version of the protocol. It is also to make client development easier (so that clients don't have to support a large set of features to do basic things) and for situations where rich text is just technically not feasible. I just also took a look at two popular proprietary apps: Slack messages have two alternatives: one is plain text or markdown, the other one is using "blocks" [https://api.slack.com/block-kit/building]. Every message must have the plain/markdown version, blocks are optional, but if present should be preferred for rendering. Notifications on mobile (which are transported through the heavily restricted OS native push messaging systems) always use the plain/markdown variant. Microsoft Teams messages can be plaintext or HTML. Both have a plain text "summary" which is the same as the body for plain text messages and is meant for push notifications and as a fallback for when HTML rendering is not possible. To me it rather looks like whenever a complex markup system is available (HTML, "Blocks") a simple version (plain text, markdown) is provided as a fallback. Of course a lot of messengers just only support plain text or markdown and are fine with it, especially as inputting any formatting on mobile is tedious. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
