Hi, Sorry, long mail ahead.
I'd like to express that I am very much unhappy where this is leading. While I am personally not a big friend of inline message styling, I kind of feel that the party of non-likers (or parts thereof) is trying to make the XEP to something that is mostly useless instead of improving it. In several discussions, I've been trying to maintain a more neutral position, even though I personally do not like 0393. So I'm putting up my thoughts here now (and a conclusion). There are some advantages of using the inline styling directives as described in 0393 for users: - No sender support required: Even if your sending client is not aware of XEP-0393, you can use it to do styling that is understood by other clients that are XEP-0393 capable. - Transport agnostic: Inline tyling works through gateways. It works through body-only encryption. As long as there is no widespread deployment of OMEMO 0.4+ or PGP-OX, there is no better way to send encrypted messages with styling other than inline. Some advantages are not exclusive to 0393 as they can be implemented purely on the sending side with other kinds of markup XEP, however they are implied by 0393. - No recipient support required: Even if your client does not make "*bold*" bold, it's clearly visible that this is emphasized. Support for XEP-0393 will improve user experience, but is not required to transfer the information of emphasizing a part of the message. Not being required on the receiving end is listed as a requirement in the XEP itself. - Prior art: Some people are/have been used to doing it before, including outside of XMPP. Using what is already done in practice for emphasizing improves user experience as people don't have to change anything but still get new features. For example Thunderbird actually renders "*bold*" in bold when reading a mail (not during writing it and not for HTML mails). Some disadvantages for users are: - False positives: No matter how strict you do the rules, there is always a little chance of having a false positive, resulting in wrong styling being applied. This is mitigated partially by requiring clients to display styling directives. While there is still wrong styling, the intended message is still fully readable, it "just" looks a bit more ugly compared to when no styling was applied. Clients can also reduce the likeliness of this to happen by adding the styling directly inline in the text entry field where users type, so they will visually see when their input would cause wrong styling. - Aesthetics: Users of clients not supporting XEP-0393 will e.g. see asterisks around emphasized words, but users may not like to see them and would rather prefer to not have any emphasizing displayed at all. This is mitigated partially by requiring clients to display styling directives, thus this disadvantage applies to all users, not only those of non-supporting clients. Sending users are thus well aware that those characters are displayed. The requirement to display "ugly" styling directives also increases the need for an additional standard that does not use inline styling directives. Another kind of disadvantage: - Ideological: Styling and content shouldn't be mixed. While I do agree to this from protocol design, I don't think it's a disadvantage for users on its own. I am still putting it as it comes up a lot. The actual disadvantages are those like I described above which are inevitable when mixing styling and content. As it is the pure nature of 0393 to have styling and content mixed, this is not up for discussion. Thus any change we do should try to (further) mitigate or completely get rid of the disadvantages, ideally without having to give up on the advantages. Now the suggestion is to add both opt-in and opt-out flag and leaving it open what happens when no flag is present, apparently hoping for it eventually meaning the same as opt-out, while it currently means same as opt-in. So how does this change affect aforementioned advantages and disadvantages: - False positives can still happen as long as no opt-out flag is used. So I'd say that opt-out improves around that disadvantage, but does not completely mitigate it. - Styling directives will still be displayed by non-supporting clients and should also continue be displayed for supporting clients (as a mitigation to false positives), so there is no improvement around aesthetics. - Both opt-in and opt-out are no longer transport agnostic, which means at least partially getting rid of advantage 2. If opt-in flag remains optional, this only means that opt-out flag can be lost and even if opt-out flag is applied, styling may occur (making the opt-out flag less useful). - Having a required opt-in flag means getting rid of advantage of no sender support and transport-agnostic completely. What I meant in the introduction with "making it mostly useless": A required opt-in means the two distinct advantages of inline styling will be lost. If opt-in is required, it would be possible to implement the two other advantages using for example 0394 on the sender side: the sending client just parses the 0393-like styling from the input box and adds corresponding 0394 markup. Styling directives are left untouched in the body. Of course that's more implementation work for the sending client, but for the user it results in the same advantages and disadvantages as a required opt-in flag for 0393. So my conclusion: - We can add the opt-out flag to 0393. Supporting it is SHOULD on the recipient side and support for adding it is a MAY on the sender side. Making support a MUST both on sending and receiving side is unrealistic due to it just not being possible through transports and currently deployed encryption. - We put our energy into building a replacement (being it 0394 or something completely different) instead of using it to make 0393 less useful to harm its adoption. Marvin PS: As a sending client you can already opt-out using a hack: By prepending the opening (and, if needed, closing) styling directive with zero-width space (U+200B), the styling directive becomes invalid, stopping the receiving client from applying styling. This can actually be done per styling directive instead of per-message as the suggested opt-out flag, allowing for the sending user to disable styling where it would result in a false positive without affecting other styling in the same message. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
