Comment 141 for bug 10883
Revision history for this message
|
|
#141 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
(In reply to mikeweilgart from comment #59)
> (In reply to Jorg K (GMT+2) from comment #56)
> > When in a plain text composition, it would read:
> > Convert message to rich text (HTML).
> > That would show the formatting toolbar, add the usual HTML options, like
> > delivery mode, to the menu and convert the content of the message. Turn what
> > I called embellishment (*bold*, _underline_, /italics/) into the respective
> > HTML tags. That's quite hard, I think, since we also need list processing
> > and superscripts (x^2).
>
> I vehemently disagree with this interpretation of the proposal. First, if
> that type of formatting is desirable, there are plugins such as "Markdown
> Here" that can be used to accomplish that. Second, it means that converting
> to HTML is actually a *lossy* change, not lossless.
>
> Under all circumstances, switching from plaintext composition mode to HTML
> composition mode and then back again without making edits should be
> effectively identical to not switching at all.
>
> Switching from a *formatted* HTML email to plaintext email is unavoidably
> lossy. There should be an alert dialog about that, just as there is in
> Outlook or Apple Mail, and that's fine. But trying to be "smart" when
> converting plaintext to HTML, when that wasn't *explicitly requested*, would
> be a nightmare.
I agree with comment 58 and comment 59 that "smart" upgrading from embellished plaintext to real HTML formatting is a can of worms that should be avoided. We really can't predict the meaning of such embellishments, and we could never remove the embellishment characters (as we already don't remove them when reading them as formatting within plaintext), so user needs to go through all of his text anyway to remove them, then it's just the same to apply formatting where wanted.
Let's be honest, up- and downgrading of messages doesn't make much sense. Better don't start in plaintext mode when you want formatting. Better don't start in HTML mode when you don't want formatting and you want to be sure of that (otherwise, current auto-detect will just down-convert to plaintext for you when there's (almost) no formatting). I think the need for this feature has also become much less now that "Edit as new" of plaintext messages will go into HTML mode when that's your default. So users are much less likely to get stuck in plaintext mode against their will, which I guess was one of the key use cases for this feature. Please note that (at least after our message formatting/
> Plus, omitting this "smart" behavior would also make the feature
> tremendously simpler to implement. (And do so without breaking user
> expectations.)
+1
> I think the best description of the desired behavior has already been given
> (in the first comment on bug 216132):
>
> > I'd like to add a button to the mail compose window. Clicking on this button
> > would toggle editor between plain text and HTML. This may not even be possible.
> > Just something that came up in the forums that I thought was a good idea.
> >
> > You would also need a dialog to come up and warn the user when converting from
> > HTML to plain text about loss of formatting data.
+1
> Can someone point at the specific source code file(s) where such a feature
> would likely live?
The UI lives here (XUL, Mozilla's outphasing XML/HTML flavor for UIs):
https:/
A lot of respective code lives here (javascript):
https:/
If you just imitate the way other similar commands are set up between XUL and javascript, there's a good chance to get this part right.
Some of the deep stuff code may live here (this is the harder part, depending on how this will be implemented; C++):
https:/