360904 - Support creating formatted message as text/enriched

Status: NEW

(MailNews Core :: Composition, enhancement)

Description

[Philip Chalmers]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: version 1.5.0.8 (20061025)

After searching the Web for "Thunderbird rich text" I've found no way to create a rich text email in T-bird, i.e. one which supports bullets, font and colour changes, bold, indent.

Most email clients support Rich Text (notably Outlook & Outlook Express), and lack of rich text support in T-bird will be a big barrier.

I suggest:
* global option to define default outgoing format.
* account option to follow global option (the default) or specify account-specific default format (default to plain text).
* option in "compose message" window to switch format. When switching from plain to rich text: convert all paragraphs which begin with "*" to bullets and make word-wrapping fit to window rather than wrap at X characters; switch to preferred RTF font. When switching from rich to plain, convert all bullets to paragraphs which begin with "*" and word wrap; convert all text to monospace.
* replies should default to the format of the most recent reply or the original message, but it should be possible to switch.



Reproducible: Always

Steps to Reproduce:
1. See description
2.
3.

Actual Results:  
See description

Expected Results:  
See description

Comment 1

[Matthias Versen [:Matti]]

Why should we add another format ?
You can do all the formating with the open HTMl standard and I can't see a reason why an RTF Editor should be added.

Comment 2

[Philip Chalmers]

(In reply to comment #1)
> Why should we add another format ?
> You can do all the formating with the open HTMl standard and I can't see a
> reason why an RTF Editor should be added.
> 

First I'll define what I'm talking about, in case there's a misunderstanding.

To me, HTML email is effectively a web page sent via email, and can contain:
* active content such as scripts, objects, plug-ins, and embeds - all of which can be used by spammers and malware prepetrators.
* requests for remote resources such as images and CSS, which spammers can use to confirm that a message has been received and processed.
* links disguised under images - a favourite technique of the "please confirm your account details" type of scam.
Most email users have clients which are less well protected against spam, scams and malware than T-bird, and therefore have a negative attitude to HTML emails - and some tell their email clients to block HTML emails.

Rich text email provides similar formatting facilities to those of many forums (e.g. phpBB), including text-only links, but without the dangerous features of HTML email as defined above.

Rich text email is a major advantage for serious correspondence about fairly complex subjects because of the ability to provide bullet lists, bold for emphasis, italics for emphasis or for e.g. titles of books / articles, different fonts for section headings, etc.

And the ability to switch easily between formats in the "compose message" window is important:
* it means the user does not have to remember that the default (currently only) format is set in a section of the Account dialogue.
* it allows the user to switch if he / she realises that a message is more complex than he / she first thought. Without this, the user would have to change the setting in Accounts, create a new message, copy the text in from the previous "compose" window, etc. - and finally restore the setting in Accounts to its original value.

Finally, T-bird is the key to more widespread acceptance of the Mozilla foundation's efforts:
* most Internet users use email more than they use browsers.
* for organisations, there's no point in switching to Firefox if they have no adequate replacement for Outlook, because using Outlook exposes them to all the hazards of using Internet Explorer. Outlook can switch easily between plain text and rich text, and T-bird can't afford to be inferior to Outlook in this respect.

Comment 3

[Mike Cowperthwaite]

(In reply to comment #2)
> First I'll define what I'm talking about, in case there's a misunderstanding.

But you fail to define whether you're talking about text/enriched (RFC1896) or text/richtext (RFC1341 / RFC1521), or text/rtf (RTF is a proprietary Microsoft format).  Support for RTF is not going to happen.  Support for creating mail as text/enriched is feasible.

Comment 4

[Philip Chalmers]

(In reply to comment #3)
> (In reply to comment #2)
> > First I'll define what I'm talking about, in case there's a misunderstanding.
> 
> But you fail to define whether you're talking about text/enriched (RFC1896) or
> text/richtext (RFC1341 / RFC1521), or text/rtf (RTF is a proprietary Microsoft
> format).  Support for RTF is not going to happen.  Support for creating mail as
> text/enriched is feasible.
> 

I didn't realise there were so many standards for rich text. Basically I'm arguing for whatever:
* works for the greatest number of email users' clients. Note that is not the same as the greatest number of client packages. http://css-discuss.incutio.com/?page=StyleInEmail appears to suggest that 
* provides the formatting capabilities I described and avoids the security / privacy hazards of HTML emails.

After a very quick google I get the impression that:
* text/enriched has superseded text/richtext.
* Outlook 2000 and later use text/enriched (see http://css-discuss.incutio.com/?page=StyleInEmail).

Comment 5

[Vladimír Solnický]

I think that adding a method to convert from Mozilla e-mail HTML to text/enriched as another option to the existing converter to text/plain should be enough. Together with adding one more option to the dialogue windows asking if to send in text/plain or HTML and an option to chose if I prefer text/html or text/enriched for composing. The address book needs another value added to the current "user prefers HTML e-mail". I think options could be hidden in Thunderbird (I use Seamonkey and would like to have them there but it is another story) not to fill up the UI.

Regarding the dialogue box that asks what format to use: I would suggest (in case text/enriched is allowed) to propose all three single variants and only one of possible compounded variants; I think mutipart/alternative should always contain only text/plain + the preferred variant of rich format (either text/enriched or text/html according to the setting). So only one line would be added to the list of choices (with text/enriched alone).

The last thing to discuss is a behaviour when composing either a reply or a message forwarded inline. For this I suggest to convert the text/enriched part of the source message to text/html and continue as composing a new message using  a text/html message. It means a possible lossy conversion text/enriched-->text/html-->text/enriched and this is not to clean (especially as the enriched->html converter is not quite good now--see the bug 16197), but it is much, much better that not using it at all. And it does not take too much effort to implement. See also the related bugs: the bug 234980 and bug 65159.