[Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071
jonas at wielicki.name
Sun Mar 18 11:31:26 UTC 2018
On Samstag, 17. März 2018 21:33:54 CET Tedd Sterr wrote:
> 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.
I have to admit I haven’t followed the whole thread, but how did you folks
overlook that text colouring is on my todo, using XEP-0392-based support?
Which essentially means: you can use any colour, but you can’t select
brightness and saturation. Those will be selected by the receiving client
based on the background so that the colour is always contrastful and not hard
to read. Bonus for Color Vision Deficiency corrections.
I think this is a very valid compromise. XEP-0392 is designed so that
perceptually, you’ll see the same color as reasonably possible, even though it
might have quite different RGB values on your side than on the receiving side
(due to the inverse-background mixing).
I’ll catch up with the thread later and argue specific points if I find
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards