Bugzilla

WOW. [...]

(In reply to Henry Wilkes [:henry] from comment #71)
> there are only really 5 states:
> 
> 1. Always only send plain text.
> 2. Always only send html.
> 3. Always send both html and plain text.
> 4. Send plain text if the message is plain, otherwise send both html and plain text.
> 5. Send plain text if the message is plain, otherwise send only html.

Thanks Henry for the correct and concise listing of the 5 possible resulting behaviours.

(In reply to Henry Wilkes [:henry] from comment #77)
> Note, if we're ditching state 5, then the remaining options align with the 4 menu items in the compose window's "Options: Delivery Format" menu, with state 4 aligning with "Auto-detect". So we could use this preference to simply select one of the 4 by default when loading the compose window.

That's the basic idea of what I proposed 6 years ago in bug 1228846. Only at the time I was probably still struggling with the actual behaviour and usefulness of `Send messages as plain text if possible`, the checkbox for which was introduced following my advocacy to address significant user dissatisfaction with the destructive and unpredictable algorithm of auto-downgrade at the time (now mostly tamed).

**I propose to keep state 5, which combines the best of both worlds and produces perfectly trimmed and simple messages.
I would even propose that as Thunderbird default.**
More below.

I have significant doubts about offering users a choice to default to dataloss without warning with `1. Always only send plain text.`
If Ben insists on supporting that option, I would consider not exposing it in the UI.
If we keep it in the UI, it needs a strong dataloss warning - and composition UI should also have some warning indication.

(In reply to Alessandro Castellani [:aleca] from comment #78)
> > 2. Always only send html.
> 
> I'm not against having 4 options instead of 3, but does this option really make sense?

We currently have 4 options in the delivery format menu, so I think it's about having 5 or 4?

Iiuc, you're asking if option `2. Always only send html` makes sense?
This option will make a *lot* of sense to many users, and we have ample evidence for that on bugs, the latest being bug 1759668 which Matt filed based on user support issues.
*Especially enterprise will need a reliable wysiwyg option where Thunderbird does not alter with their messages in any way compared to what they see in composition. At the same time, this option skips the unnecessary and wasteful plaintext duplicate copy of each message, which also simplifies the message structure. All common, modern mail clients and webmail can handle HTML and do not need nor show the plain text part ever.*

> Do we know the reasons why a user might not want to send also plaintext? Are these reasons valid to justify this extra option?
> I don't have a strong opinion on this, I'm just asking as I'm curious about the usefulness of that option.

Why should we force 30 million users to send double copies of their messages (HTML+plain) whereas the vast majority of recipients (99%?) will never ever look at the plain text part? That's wasteful and inefficient. Simple message structure needs less parsing, and is environmentally friendly (transmission and long-term running server space).

(In reply to Ben Bucksch (:BenB) from comment #79)
 
> There's no real technical argument to send only HTML, given that HTML-capable mail readers will just ignore the plaintext part, and non-HTML mail readers will use the plaintext part.

Imho, sending cleaner and leaner messages is a good technical argument for sending only HTML.
Can you provide examples of modern and common non-HTML mail readers?
A non-HTML reader would render most of today's really circulating email useless, so such clients could serve only a very tiny fraction of users (1%?). Let's be honest, MUTT is an extreme niche case.

WOW. [...]

(In reply to Henry Wilkes [:henry] from comment #71)
> there are only really 5 states:
> 
> 1. Always only send plain text.
> 2. Always only send html.
> 3. Always send both html and plain text.
> 4. Send plain text if the message is plain, otherwise send both html and plain text.
> 5. Send plain text if the message is plain, otherwise send only html.

Thanks Henry for the correct and concise listing of the 5 possible resulting behaviours.

(In reply to Henry Wilkes [:henry] from comment #77)
> Note, if we're ditching state 5, then the remaining options align with the 4 menu items in the compose window's "Options: Delivery Format" menu, with state 4 aligning with "Auto-detect". So we could use this preference to simply select one of the 4 by default when loading the compose window.

That's the basic idea of what I proposed 6 years ago in bug 1228846. Only at the time I was probably still struggling with the actual behaviour and usefulness of `Send messages as plain text if possible`, the checkbox for which was introduced following my advocacy to address significant user dissatisfaction with the destructive and unpredictable algorithm of auto-downgrade at the time (now mostly tamed).

**I propose to keep state 5, which combines the best of both worlds and produces perfectly trimmed and simple messages.
I would even propose that as Thunderbird default.**
More below.

I have significant doubts about offering users a choice to default to dataloss without warning with `1. Always only send plain text.`
If Ben insists on supporting that option, I would consider not exposing it in the UI.
If we keep it in the UI, it needs a strong dataloss warning - and composition UI should also have some warning indication.

(In reply to Alessandro Castellani [:aleca] from comment #78)
> > 2. Always only send html.
> 
> I'm not against having 4 options instead of 3, but does this option really make sense?

We currently have 4 options in the delivery format menu, so I think it's about having 5 or 4?

Iiuc, you're asking if option `2. Always only send html` makes sense?
This option will make a *lot* of sense to many users, and we have ample evidence for that on bugs, the latest being bug 1759668 which Matt filed based on user support issues.
*Especially enterprise will need a reliable wysiwyg option where Thunderbird does not alter their messages in any way compared to what they see in composition. HTML formatting has the highest chances of rendering as intended with the recipient. At the same time, this option skips the unnecessary and wasteful plaintext duplicate copy of each message, which also simplifies the message structure. All common, modern mail clients and webmail can handle HTML and do not need nor show the plain text part ever.*

> Do we know the reasons why a user might not want to send also plaintext? Are these reasons valid to justify this extra option?
> I don't have a strong opinion on this, I'm just asking as I'm curious about the usefulness of that option.

Why should we force 30 million users to send double copies of their messages (HTML+plain) whereas the vast majority of recipients (99%?) will never ever look at the plain text part? That's wasteful and inefficient. Simple message structure needs less parsing, and is environmentally friendly (transmission and long-term running server space).

(In reply to Ben Bucksch (:BenB) from comment #79)
 
> There's no real technical argument to send only HTML, given that HTML-capable mail readers will just ignore the plaintext part, and non-HTML mail readers will use the plaintext part.

Imho, sending cleaner and leaner messages is a good technical argument for sending only HTML.
Can you provide examples of modern and common non-HTML mail readers?
A non-HTML reader would render most of today's really circulating email useless, so such clients could serve only a very tiny fraction of users (1%?). Let's be honest, MUTT is an extreme niche case.

WOW. [...]

(In reply to Henry Wilkes [:henry] from comment #71)
> there are only really 5 states:
> 
> 1. Always only send plain text.
> 2. Always only send html.
> 3. Always send both html and plain text.
> 4. Send plain text if the message is plain, otherwise send both html and plain text.
> 5. Send plain text if the message is plain, otherwise send only html.

Thanks Henry for the correct and concise listing of the 5 possible resulting behaviours.
**I propose to continue supporting all of them.**

(In reply to Henry Wilkes [:henry] from comment #77)
> Note, if we're ditching state 5, then the remaining options align with the 4 menu items in the compose window's "Options: Delivery Format" menu, with state 4 aligning with "Auto-detect". So we could use this preference to simply select one of the 4 by default when loading the compose window.

That's the basic idea of what I proposed 6 years ago in bug 1228846. Only at the time I was probably still struggling with the actual behaviour and usefulness of `Send messages as plain text if possible`, the checkbox for which was introduced following my advocacy to address significant user dissatisfaction with the destructive and unpredictable algorithm of auto-downgrade at the time (now mostly tamed).

**I propose to keep state 5, which combines the best of both worlds and produces perfectly trimmed and simple messages.
I would even propose that as Thunderbird default.**
More below.

I have significant doubts about offering users a choice to default to dataloss without warning with `1. Always only send plain text.`
If Ben insists on supporting that option, I would consider not exposing it in the UI.
If we keep it in the UI, it needs a strong dataloss warning - and composition UI should also have some warning indication.

(In reply to Alessandro Castellani [:aleca] from comment #78)
> > 2. Always only send html.
> 
> I'm not against having 4 options instead of 3, but does this option really make sense?

We currently have 4 options in the delivery format menu, so I think it's about having 5 or 4?

Iiuc, you're asking if option `2. Always only send html` makes sense?
This option will make a *lot* of sense to many users, and we have ample evidence for that on bugs, the latest being bug 1759668 which Matt filed based on user support issues.
*Especially enterprise will need a reliable wysiwyg option where Thunderbird does not alter their messages in any way compared to what they see in composition. HTML formatting has the highest chances of rendering as intended with the recipient. At the same time, this option skips the unnecessary and wasteful plaintext duplicate copy of each message, which also simplifies the message structure. All common, modern mail clients and webmail can handle HTML and do not need nor show the plain text part ever.*

> Do we know the reasons why a user might not want to send also plaintext? Are these reasons valid to justify this extra option?
> I don't have a strong opinion on this, I'm just asking as I'm curious about the usefulness of that option.

Why should we force 30 million users to send double copies of their messages (HTML+plain) whereas the vast majority of recipients (99%?) will never ever look at the plain text part? That's wasteful and inefficient. Simple message structure needs less parsing, and is environmentally friendly (transmission and long-term running server space).

(In reply to Ben Bucksch (:BenB) from comment #79)
 
> There's no real technical argument to send only HTML, given that HTML-capable mail readers will just ignore the plaintext part, and non-HTML mail readers will use the plaintext part.

Imho, sending cleaner and leaner messages is a good technical argument for sending only HTML.
Can you provide examples of modern and common non-HTML mail readers?
A non-HTML reader would render most of today's really circulating email useless, so such clients could serve only a very tiny fraction of users (1%?). Let's be honest, MUTT is an extreme niche case.