Auto collect "prefers html" info

RESOLVED INVALID

Status

MailNews Core
Composition
--
enhancement
RESOLVED INVALID
16 years ago
3 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

RFE:  auto collect "prefers html" info

recently I've been trading emails from someone who is sending me html email.

every time I reply to them, it asks me "send in html?"

it seems like if I get an email from someone, and it is in html, and they are 
in my addressbook (personal?  collected?  both?) and I have "unknown" for 
prefers html (so not html and not plain text), we should mark it as prefers 
html.

comments?

Comment 1

16 years ago
sure, yes, we've talked about this in the past. We'd probably need to get a
little more info from mime when populating the history ab to do this. I'm not
sure if Mime has finished parsing the message or not by the time it gives us the
headers - if not, we'd probably need to postpone the notification until it had
finished parsing the message and thus knew if the msg was html.
I am pretty sure mime is done parsing the headers at this point, therefore it
wil be trivial to retreive the needed info...

Comment 3

15 years ago
*** Bug 179002 has been marked as a duplicate of this bug. ***
Product: MailNews → Core

Updated

10 years ago
Assignee: ducarroz → nobody
QA Contact: esther → composition
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
Summary: RFE: auto collect "prefers html" info → Auto collect "prefers html" info
Blocks: 889315
(In reply to (not reading, please use seth@sspitzer.org instead) from comment #0)
> RFE:  auto collect "prefers html" info
> 
> recently I've been trading emails from someone who is sending me html email.
> 
> every time I reply to them, it asks me "send in html?"

TB has long stopped using "Ask me" as default setting. Which removes the main scenario of this bug.

> it seems like if I get an email from someone, and it is in html, and they are 
> in my addressbook (personal?  collected?  both?) and I have "unknown" for 
> prefers html (so not html and not plain text), we should mark it as prefers 
> html. comments?

I think this bug is trying to solve problems which no longer exist.
This hasn't had any supporting comments nor duplicates nor votes since 2002 when it was filed.
I think adding more complexity to recipient-centric logic is no longer needed nor wanted, because sending HTML is no longer a big deal. The general assumption in 2015 is that everyone can receive HTML; for those few who can't or don't want, user can set "prefers-plain" per-recipient or per-domain.
So we should offer the user general settings to default to sending HTML, or both plain text and html.

Two better solutions:

1) Recipient-centric: Allow global mapping of "prefers-unknown" to "prefers-something" (plain|html|both; Bug 1222176).

2) Message-centric: Allow per-identity setting of stable default-delivery format for new compositions (auto-detect | plain(?) | html | both). Along bug 136502, but we have morphed that into "switch for auto-downgrade", so there's no clean bug yet. Something like "Default message delivery format" option seen at the top of attachment 8673807 [details].

So I think this bug can be closed. Any objections?
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
This is essentially a duplicate of bug 306303, which has a more detailed but still insufficient description. So my comment on the other bug also applies here.

(In reply to Thomas D. from bug 306303 comment #14)

> - "Ask me" is no longer the default, so the main motivation of this bug (to
> avoid the nagging) is gone.
> - We have Auto-Downgrade for sending simple HTML messages as plaintext (when
> they look like plaintext because there's virtually no HTML formatting).
> - For all other types of messages (non-trivial HTML), most users just want/need to
> send HTML from HTML compositions, to preserve the formatting (UX-wysiwyg).
> - In 2015, HTML is no longer a problematic send format
> - In view of the above, switching every contact explicitly to "prefers-HTML"
> isn't necessary nor helpful, when all we originally wanted here is to "just
> let me send HTML without getting asked".
> Per-Recipient settings are a very clumsy and hard-to-reverse way of
> achieving that.

Instead (kinda reversing the idea of this bug), user should explicitly set "prefers-plain" for those few recipients (if any) who *cannot* handle HTML; for any other recipients, we can safely assume that they can handle HTML, and allow the user to default to sending that (with or without Auto-Downgrading when particular message has virtually no formatting).

> And if we are very honest, since everybody can receive HTML messages (even
> when some devices might downgrade them for the recipient) nobody cares much
> about the recipient's actual preferences.
> It's much more message-centric these days, so if my message content requires
> HTML formatting, I'll just send that without thinking about recipients.
You need to log in before you can comment on or make changes to this bug.