[Maildev] Engineering Council or Engineering Steering Committee (ESC) - where art thou?

Ben Bucksch ben.bucksch at beonex.com
Fri Aug 31 19:14:15 EDT 2018


Well, Outlook can't quote properly. (Just like K9 mail can't.... sigh...sorry!) so, if outlook users need to respond to specific sentences, instead of using proper standard > quotes (which outlook can't do properly), they often use color to separate quote and reply. color *only*. the problem is... i don't see these colors. so, on my end, i see a complete mess of an email, because i can't tell who says what. ... that's just one concrete example of what's wrong with colors in email.

there are many reasons why people might not see colors. I'll just list a few of them:
1. color blind (a large percentage of males are red/green color blind)
2. text only email client
3. corporate firewall that down-converts everything to plaintext (i've seen these in large orgs, for security reasons)
4. e.g. Simple HTML feature in thunderbird, for security, or because our user needs his own font, to be able to read emails properly and quickly.

any of the above will mean that the recipient will not see the color. so, it's a bad idea to use them for semantic.

if it was my decision, i would not allow senders to set color or fonts. i concur with Magnus here. but i could see many users opposing that, so if that's considered to drastic, then ...

at least the color UI should be specific, never the default, and the UI should be fairly hidden (e.g menu item only, no toolbar buttons), and come with warnings that educate the user.
i would trust Richard to find a nice UI solution, considering these concerns.

Ben

Am 31. August 2018 22:23:01 MESZ schrieb Mark Rousell <mark.rousell at signal100.com>:
>On 31/08/2018 19:27, Ben Bucksch wrote:
>> Colors are not part of HTML. (they were at one point in time, but
>they
>> were neither originally, nor are now)
>>
>> HTML is about structure, not presentation. the reader software can
>> present the structure in a way that is pleasant to the reader user.
>>
>> i think this is very appropriate for the email context.
>
>Oh come on, you're joking aren't you? ;-) As you know, when people talk
>about "HTML emails" they are not being literal. HTML emails today can
>(and do) include CSS if you feel that HTML alone should not include
>presentation attributes.
>
>Out there in the real world, HTML emails (both with or without CSS)
>include colour. It doesn't really matter whether the colour information
>is done directly in HTML elements or via CSS, but the fact remains that
>HTML emails can and do include coloured text and backgrounds and it is
>necessary for Thunderbird to be part of this world.
>
>In an ideal world, sure, it would be nice if the recipients of emails
>could choose exactly how they were presented but that's a job for their
>own mail client. It is ultimately up to their mail client to parse
>incoming emails and show only those elements or attributes (either HTML
>and/or CSS) that the user wishes to see.
>
>In the context under discussion here, like it or not, if we want TB to
>be competitive in the modern world then it does need to give users the
>chance to compose HTML-encoded emails either with colour or without, as
>they prefer. Exactly how their colour preferences are encoded in actual
>emails (e.g. old fashioned HTML tags and attributes or funky up to date
>embedded CSS) is largely a separate question.
>
>-- 
>Mark Rousell
> 
> 
> 

-- 
Sent from my phone. Please excuse the brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/attachments/20180901/0942e2ec/attachment.html>


More information about the Maildev mailing list