I didn't expect this to turn into a drawn-out argument; I merely suggested a simple solution to something that could otherwise be seen as a problem. Nor am I continuing it for my own amusement, but I genuinely don't understand why it's such a contentious issue for some.
So far the main argument against including text colouring seems to be "because I don't want it, so nobody else should have it either" which is really quite ridiculous, especially when there are genuine arguments that could be made. In search of clarity, here are all of the reasons against that I can think of, and replies to those. Please correct me if I've misunderstood anything; and additional sensible reasons are also welcome. (TL;DR: If you don't want to support text colouring, you don't have to, but that is not a reason to stop others from supporting it - skipping unsupported spans is necessary to support 0394 properly anyway. If you do support text colouring, allow users to disable it.) 1. "I don't want to use text colouring, nor do I want to receive it." That is a valid viewpoint, and your eyes should not be forced to endure anything but the highest quality of monochrome text displays. If your client supports text colouring, then it should necessarily provide an option to disable it and thus your eyes will be saved; if your client doesn't support it, then all text colouring will be safely ignored, you will be treated to nothing but the finest default text colour and thus your eyes will be saved. 2. "People could send crazy multi-coloured messages and the ugliness of it all would irritate me." They could, but as long you're not the one receiving them it shouldn't be a problem for you. If you are the one receiving them, then much as above, your client should allow you to disable it or simply won't display it in the first place - either way, you're saved from irritation. 3. "If my client has a black/white/pink/green background and somebody sends me text of the same colour, I won't be able to read it." This could very easily be handled automatically by the receiving client (as I have previously suggested.) But as has been pointed out, neither email, nor web browsers have made any attempts to do so; which really only demonstrates how much of a non-issue it is in practice. Again, clients that support text colouring should allow users to disable it, and it makes no difference for clients that ignore it. 4. "It's bad for accessibility." Absolutely! And for this reason alone, clients should allow users to disable text colouring. But there is far more to providing good support for accessibility than simply not displaying multi-coloured text; if your client does have serious a11y support, then providing a high-contrast view and not displaying multiple colours are just some of the many options you're already providing. 5. "Optional features are bad for compatibility." XMPP is based around the flexibility of features being optional, and that works successfully because we have a mechanism for determining which features another entity supports and which they don't. The problem with things being optional stems from not knowing - if you expect something to be there but it isn't, that is a problem. However, text formatting is very much a cosmetic feature, so the worst that can happen is your text isn't displayed 100% as intended; if the client handles things sensibly, this will be entirely transparent to the receiver of the text. In the specific case of text colouring, this simply means the text will take the default colour, which is a terrible shame, but far from being a catastrophe. XEP-0394 specifically suggests this kind of opt-in functionality -- "Entities SHOULD be able to cherry-pick a subset of the markup which is suitable for their presentation (for example, a terminal-based client may support inline emphasis and strike through, but no block-level markup)." 6. "I shouldn't have to code special cases to ignore markup so you can include features that I have no interest in supporting." Quite right - this is an argument I could actually agree with, except it's not necessary. XEP-0394 is intended to be extensible, with potential future features to extend the base set -- "The markup specification MUST be extensible in order to support more complex use-cases in the futurue.[sic]" The sensible way to do that is for recipients of 0394 formatted messages to simply skip over spans or blocks they don't understand or support; this means any future additions will not cause problems for recipients that don't understand them, without the need for namespace bumps or numerous capability identifiers. So, irrespective of text colouring, you will be required to skip over spans or blocks that you don't support; you won't need additional special casing to ignore text colouring, it will be one of many potential spans that you don't support. 7. "If we include this feature, then somebody else wants another feature, and someone else another... where does the madness end?!" Reductio ad absurdum. We could apply the same reasoning against the inclusion of enumerations, itemized lists, headings, paragraphs, and code blocks - all features Jonas suggested he aims to include, in addition to "XEP-0392-based colors" - but we won't do that because it would be silly. It is a useful feature, and one that is desired by some. It's not some absurd feature that nobody wants - text colouring is already supported by a number of clients (using XEP-0071.) If XEP-0394 is intended to be an adequate replacement for XEP-0071, and 0071 supports text colouring, then 0394 should at least attempt to also support text colouring - as long as doing so does not introduce security issues or otherwise cause problems for users.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
