Closed Bug 38433 Opened 24 years ago Closed 24 years ago

Recommend plaintext, if reasonable

Categories

(MailNews Core :: Composition, defect, P1)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: BenB, Assigned: BenB)

References

Details

(Whiteboard: [nsbeta2-] Fixed.)

Attachments

(12 files)

Fix, version 1: |cd mozilla/mailnews/compose; cvs diff -u .|
16.70 KB, patch
Details | Diff | Splinter Review
Fix, version 2
18.53 KB, patch
Details | Diff | Splinter Review
Fix, version 4
19.72 KB, patch
Details | Diff | Splinter Review
Fix, version 5
20.35 KB, patch
Details | Diff | Splinter Review
Fix, version 6 - Factoring out some code to reduce redundancy
20.94 KB, patch
Details | Diff | Splinter Review
Screenshot of current impl., case convertable
8.35 KB, image/png
Details
Screenshot of current impl., case not convertable
7.56 KB, image/png
Details
Fix, version 8
27.54 KB, patch
Details | Diff | Splinter Review
Fix, version 9
27.58 KB, patch
Details | Diff | Splinter Review
Fix, version 10, mailnews/composer
27.93 KB, patch
Details | Diff | Splinter Review
Fix, version 10, skin changes
13.09 KB, patch
Details | Diff | Splinter Review
Fix, version 10, Icons
2.16 KB, application/x-zip-compressed
Details 
Description:
We can convert several HTML tags to plain text without data loss:
ul, ol, li, blockquote (without cite),
b, i, u, strong, em, code,
a

We should suggest plain text in the askSendFormatDialog, if the msg contains
only those (and <html> etc.) tags. In other cases, we should force a decision by
giving no default like we did in the past im Mozilla Mailnews.

Importance:
This is important interop. nsbeta2 nomination.
Newbies have no idea, if it will loose data and take the "save" choice to HTML
(or HTML+plain text), if not necessary, which causes hostile reaction on the
other end.
Power users like myself know, that Mailnews can convert it and use those tags in
the HTML composer, even if they intend to send plain text. They would save one
click.

Implementation:
If I get the checkin permission then, I could do some of this, namely the
checks, for M18. However, somebody else would have to give the
askSentFormatDialog the ability to take a default.
I'll wait with the nsbeta2 keyword for Phil's answer.
Phil, can we move this bug to M18 or is it considered a "feature"? I really want
this to be in the shipping product.
It's a feature to have a list of HTML tags which force the "ask me" dialog.
Assuming we have that code (in 4.x, the list was <html>, <p>, <br>, etc.) I'm
willing to consider the optimization of that list as a bug.

I like the idea of automatically sending simple messages as plain text, and 
also of forcing a decision when the message can't be easily converted to plain 
text (as long as there's a "[don't] ask me again" checkbox on the dialog).  I 
don't think that list should include <b>, etc, though, because it doesn't 
always look good to surround text with ** or __, and if a user makes the text 
bold, he or she probably expects it to come out emphasized.  
Phil,
bug 28420 is about Intelligent Send. This (38433) bug is not as easy as adding
some tags to a list, since we don't yet have the ability to set the default of
the ask dialog. In other words, this bug is about enhancing the intelligence of
Intelligent Send. Would this be a "feature"? I'm asking, because I propbaly
won't have time to implement it before M18.

Jesse,
- It does come out as emphasized in Mozilla (in most cases).
- I don't know, what your concern is. Those tags (for structured phrases) *will*
trigger the ask dialog, just the default choice will be plain text. You can
easily override it. (It will not trigger, if there is only <body>, <p> etc., see
bug 28420.)
Ben, now I see you're proposing a change to the algorithm for "intelligent
send", and I guess that is a feature.

We have, in the past, discussed setting the radio buttons in the Ask Me dialog
differently based on contextual information (message contents, recipients, etc).
Personally, I'm not in favor of doing that because I think it would be confusing
to have the dialog settings and output content-type (!) change based on
unpredictable (to the user) context. Just my opinion though...

Ah, so the dialog would contain something like "Mozilla can convert your 
message to plain text.  This will make it easier for older mail programs to 
read your message, but your text formatting will be converted to ASCII hints 
(for example, <b>bold text</b> will be changed to *bold text*)."

I don't buy your argument that "[i]t does come out as emphasized in Mozilla (in 
most cases)."  It won't come out as emphasized in most HTML-readers, just 
Mozilla.  And URLs could get screwed up by the extra _fake formatting_.

By the way, should <a href="$1">$1</a> and <a href="mailto:$1">$1</a> be added 
to the list of things that get converted without asking?  This should only be 
done if it is safe to assume that most mail clients that handle HTML mail also 
add links automatically in text/plain e-mails.
> I guess that is a feature.

OK, nsbeta2 nomination. Without this "feature", my structured phrases feature
(conversion of <strong>bold</strong> -> *bold* -> <strong>*bold*</strong>) is
kind-of pointless, because it was my intention to reduce the number of
"misguided" HTML msgs with it.

> it would be confusing to have the dialog settings and output content-type (!)
> change based on unpredictable (to the user) context.

What, if we display altered text saying, that we only found "convertable" tags?
> so the dialog would contain something like

Didn't read that. Yes, that was, what I had in mind.

> And URLs could get screwed up by the extra _fake formatting_.

Please explain. "<a href="foo://url">an<b>bold</b>url</a>" -> "an*bold*url
<foo://url>"

> By the way, should <a href="$1">$1</a> [...]

This is bug 28420.
Keywords: nsbeta2
<a href="$1">$1</a> is already in the list of tag that doesn't ask user for convertion.

> "<a href="foo://url">an<b>bold</b>url</a>" -> "an*bold*url<foo://url>"

ok, so you're saying that if the href doesn't match the anchor, we include both 
the plain-texted anchor plus the url in brackets?  sounds good to me.

> that we only found "convertable" tags?

it's hard to be newbie-friendly if you use the word "tags"...
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
Does this mean, if I won't fix it for M16, it won't be in final? Or will I have
a chance for M18? I think, this is really important, but I *really* have next to
no time currently.
If JF has to do any work, it can only be done before M16. If you do the work, it
can be done after M16 if (1) you can convince mozilla.org (mitchell and whomever
she designates) to take it and (2) you can convince the module owner (probably
putterman) to take it.

Phil, tnx for clarification. REASSIGNing to myself. P1. M18 in optimism, that
I'll get the permission :-). Putterman, what do you think?
Assignee: ducarroz → mozilla
Priority: P3 → P1
Target Milestone: --- → M18
Status: NEW → ASSIGNED
As long as this is just setting defaults it sounds reasonable.  I'd take it if
it gets code reviewed by the right people and we're confident it works.  I wish
I could do this for my code :)

Also, it depends on when.  It's more likely to be taken at the beginning of M18 
than on the last day.
putterman, tnx.

/me relaxes :).
Target Milestone: M18 → M17
FIXED! Yeah! My P1 bug is done.

I will attach patches as soon as I finished testing. ducarroz, can you then
review, please?
Whiteboard: [nsbeta2-] → [nsbeta2-] Fixed.
Spent 1,5 full days finding XUL-engine bugs. *sigh* :(. At least, I found
workarounds.

ducarroz, thanks for using consts instead of numerical literals. Otherwise, one
of the workarounds would have hurted much more.

The changes to nsMsgCompose.cpp look more scary (at least to me) than they are:
I just copied the tree-walking.
Keywords: review
Maybe I should not use C++-style comments in XUL files?

BTW: Filed bug 44552 about finetuning the list of tags we ignore/recognize.
Attached patch Fix, version 2 — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix, version 4
        — 
          — Splinter Review
      

    


  

    
    

    
  
The old patch conflicted with ducarroz' latest changes. Attached new one.

ducarroz, can you review, please?

    
    

    
  
Ben, I want be able to review it until next week.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix, version 5
        — 
          — Splinter Review
      

    


  

    
    

    
  
No, WONTFIX, WONTFIX! You should *never* vary a default setting in a dialog 
unless your reason for doing so is *extremely* obvious -- and the exact 
assortment of HTML tags which a particular message happens to contain, is not 
obvious at all.

If you vary a default option like this, you make it very easy for a user who has 
learnt the contents of the dialog (and who is expecting one particular option to 
be the default) to accidentally select the wrong option -- e.g. pressing
Down,Down,Enter to select another option, without even looking at the dialog 
thoroughly.

Suggestions:
* Make the text of the recommended option bold.
* Say `(Recommended)' next to the best one for the given message.

But *please* don't change the default selected option; if you do, undesirable 
messages will result, and the (sender) victims might never work out why it 
happened.


    
    

    
  
Matthew, the length of the text in the middle is different, making the two
versions of the dialog visually obvious. So, only if you just hit Send, wait a
second and then hit enter *blindly*, you will possibly have a problem. But
that's your problem, as there might be a completely different dialog as well,
e.g. "no subject".

<example content="dialog_convertable">
recipients balbala

can be converted blavbla pwrtu pwzrtpzwtr
wzrpowrpüt.  however, the look woiezr otwe r 
we opwrt öopt äoutwoärt oärati 

do you want iwetrut ?
</example>

<example content="dialog_convertable">
recipients balbala

cannot be converted blavbla pwrtu pwzrtpzwtr



do you want iwetrut ?
</example>

    
    

    
  
(Note that the whitespace in the examples was significant, i.e. in the dialog is
really some free space between the last 2 paragraphs in the second case.)

    
    

    
  
Not relevant. Intermediate to advanced users will be smart enough to fill out 
sender, subject etc, and they will be expecting the conversion dialog to appear. 
They know what the default will be, and they will have memorized the sequence of 
key-presses required to change from the default to the particular conversion 
setting they want for this message. So they don't need to read the dialog at all.

But oops! they get it wrong, because you've shifted the default on them. Bad 
Mozilla! Bad!


    
    

    
  
(BTW: the second example was really |content="dialog_notconvertable"|.)

If internediate to advanced users always want the same setting, they can (and
most likely will) set the pref. See also bug 44494.

Not even *looking* at the dialog is operator-error. All sorts of nasty things
can happen then, and they know that.

    
    

    
  
That's assuming that intermediate to advanced users always want the same setting, 
in which case the dialog wouldn't be appearing in the first place. But this bug 
is about when it *does* appear, which means that the user has a good reason for 
altering their choice between messages.

If I know what a dialog is going to say, not looking at it is *not* operator 
error. When Mac OS draws a native dialog, it draws the Ok and Cancel buttons 
before it draws any of the other controls, for precisely this reason: if you hit 
Enter or Escape fast enough, the rest of the dialog never needs to be drawn, 
because the system knows that you know what the dialog was going to say.


    
    

    
  
> That's assuming that intermediate to advanced users always want the same
> setting, in which case the dialog wouldn't be appearing in the first place.

So, you imaginary user uses even altering settings (and propably formatting),
and never came across the second type of dialog before?

> If I know what a dialog is going to say, not looking at it is *not* operator 
> error.

Yes, and then we won't have a problem.

    
    

    
  
> So, you imaginary user uses even altering settings (and propably formatting),
> and never came across the second type of dialog before?

What's `the second type of dialog'?

> > If I know what a dialog is going to say, not looking at it is *not* operator 
> > error.
>
> Yes, and then we won't have a problem.

But we will, because the user will be assuming a default option which you have 
changed from under them.


    
    

    
  
> What's `the second type of dialog'?

If we found elements not convertable to plaintext, say so and set no default at
all.

This dialog gives the user an additional guidiance, that he really needs. A
newbie doesn't know what is the right thing to do. The right thing to do depends
on the situation. We help him by reflecting this inthe software.

Additionally, we offer a reasonable default for all users. If you just hit OK,
you say "I don't know/care, I let the software choose the right option.". That's
what we do.

If a user acts blindly without knowing the app, that's his problem, not mine.

    
    

    
  
In case my comments are lost in the upper reaches of this bug report that no one
ever reads anymore, I agree with Matthew -- it would be confusing to change the
default values in the Ask Me dialog.

> If a user acts blindly without knowing the app, that's his problem, not mine.

I completely disagree with that. If a user acts on muscle memory about where
controls are, or what their policy-based values are, and we change that,
invalidating their reasonable expectations, that's our problem.


    
    

    
  
> In case my comments are lost in the upper reaches of this bug report that no
> one ever reads anymore, I agree with Matthew -- it would be confusing to
> change the default values in the Ask Me dialog.

No, they were not at all lost. They were the reason why I added changing text in
the dialog. And this text and its visibility (it is really hard to miss it,
unless you don't look at all on the screen) are the reason why I reject Matthews
objections.

There are so many dialogs which can pop up during the send option. If a user
really thinks he knows them all, he most likely already saw both versions of the
askSendFormat dialog.

If that is not convincing: Let's go through the keystokes the user could have
remembered and see it there can actually be a problem in practice. In one case,
we set a default, in the other one we don't, so I guess, the keystrokes have to
be different to actually trigger accidently a wrong option.



    
    

    
  
bummer. No keystrokes at all currently (other than ENTER). Re ENTER: It doesn't
work in the not-convertable case, so, either the user won't even try to hit just
ENTER blindly, or it won't work.

    
    

    
  
> There are so many dialogs which can pop up during the send option.

Yes, but the content of each of those dialogs is always the same, and it's
reasonable for the user to expect them to be the same.


    
    

    
  
> If we found elements not convertable to plaintext, say so and set no default at
> all.

Setting no default at all is very bad UI. If this is even possible in XPToolkit, 
it is a bug. The only time when none of a set of radio buttons should be 
selected, is with Windows native radio buttons when two or more of them are 
selected simultaneously
<http://msdn.microsoft.com/library/books/winguide/ch08c.htm>. (E.g. for a 
paragraph formatting dialog, when part of the selected text is aligned left, and 
part is centered.) That is obviously not the case here.

If the Enter key doesn't work in a dialog, that is also a bug.

> There are so many dialogs which can pop up during the send option. If a user
> really thinks he knows them all, he most likely already saw both versions of
> the askSendFormat dialog.

No, because (as I already said) if you vary the default, she has no reasonable 
way of knowing which default is going to apply for any given message, so she 
doesn't know which `version' is going to appear. If you vary the default, 
assuming the user even realizes you are doing so (instead of repeatedly choosing 
the wrong option by mistake), you are wasting the user's time by forcing her to 
read the dialog every single time.

Please just make the recommended option bold, and/or include the text 
`(recommended)' next to it. Don't change the default.


    
    

    
  
> Setting no default at all is very bad UI
[...]
> Please just make the recommended option bold, and/or include the text 
> `(recommended)' next to it. Don't change the default.

Do you propose to have a default different from the recommended option, or what?
(*This* would be *really* bad UI, certainly the worst option of all IMO.)

There *are* two cases, we have to reflect them *anyhow*.

    
    

    
  
> Do you propose to have a default different from the recommended option, or
> what?

If the default happens to be different from the recommended option for that 
particular message, then yes.

Imposing `intelligence' which changes the default option depending on the message 
will firstly cause user errors, and secondly interfere with the user's ability to 
deal with the dialog quickly.


    
    

    
  
I think the point that's been missed in all this is that we're assuming we 
know what's best for the user better than they do.  There's the assumption 
that if a message *can* be converted to text, then it *should* be, 
regardless of what *they* know about the addressee's mail client.  They 
may not have specified that the addressee can receive HTML e-mail, but 
that doesn't mean they can't.  A better default, I think, would be to send 
plain text and HTML both, preserving the content as entered and allowing 
the mail client to process it normally.

Generally speaking, faux machine intelligence is *good.*  If we can do 
simple things to predict the users needs or focus of attention, that makes 
the product look and feel better.  But that assumes that we can reliably 
predict their desire.  If we *can't* and we predict incorrectly, then it quickly 
moves from good to downright annoying.  This is a very simple case, but 
one in which we can't reliably predict how a user, beginner or advanced, is 
going to treat each e-mail.  Better to simplify and give them a single 
solution which better matches their needs than a more complex one that 
might just confuse them.  I would recommend a single dialog, always 
defaulting to "plaintext & HTML" where the plaintext automatically gets as 
much faux formatting as possible and which explains that some 
formatting may be discarded if "plaintext only" is selected.  For example:

Mozilla can convert your message to plain text.  This will make it easier for 
older mail programs to read your message, but some text formatting may 
be lost.

(O) Send plain text and HTML.
( ) Send HTML only.
( ) Send plain text only.


    
    

    
  
> I think the point that's been missed in all this is that we're assuming we 
> know what's best for the user better than they do.

In many cases, we actually *do* know it better. I think, most, or at least many,
users don't understand the problem fully. So, we give them a good
recommondation. I argue that the fix for this bug *considerably* increases the
quality of the recommondation.

*But* I do not assume that we know it better in all cases. That's why the dialog
still pops up. The user stilll has the same choices as before, just that we make
a better recommondation now.

> A better default, I think, would be to send 
> plain text and HTML both, preserving the content as entered and allowing 
> the mail client to process it normally.

NO. Please refer to the discussion "Assuming "plain text" or "html mail".." on
.mail-news <news://news.mozilla.org/37FA67D5.C902C699@netscape.com>. This is
what 4.x did, and it caused *a lot* of complaints and problems. Many people
consider sending HTML rude, even if it's a multipart msg.

Plaintext Only is the safest choice. 4.x even says so in the help (but fails to
implement this in the software).

--

I suggest to review and checkin the patch. I argue taht it is a large
improvement over the previous state. The extend of formatting is one factor in
the calculation what format to send, and this fix reflects this in software.

What Matthew is discussion about is IMO UI polish. If we always set the same
default choice and just change the recommondation or the text, or if we change
the default choice based on the recommondation, or what the default choice
should be, is IMO important, but, from the coding perspective, just minor tweaks
to fix I submitted.

I think, setting the default based on the recommondationis the most obvious
solution for now, and we have a working patch for that. So, please let us check
this stuff in and file a new bug about the polish. But please be sure to have
consensus or at least a majority for the solution you propose in the bug.

    
    

    
  
> just minor tweaks to fix I submitted.

just minor tweaks to *the* fix I submitted.

I.e. my patch contains teh bulk of teh work, and it has to be done anyway. The
rest are just tweaks.

    
    

    
  
Ben, you completely skipped over the point of my argument, choosing to 
focus instead on a suggested example dialog.  Thank you for pointing me 
to that particular thread in the newsgroup, however, because I now see 
that this is entirely a personal issue for you and has little to do with "* a 
lot* of complaints and problems."

Back to the original point, *MOST* users don't care *what* format they're 
sending.  MOST users just want to send their mail and be done with it. It's 
generally engineers thinking they know what's best for everyone that get in 
the way and force all these different formats on people who couldn't care 
less about HTML, plain text, multi-part messages, or any other 
under-the-hood detail.

When the case arises that the user must be presented with a choice, for 
whatever reason, that choice should be clear, simple, and predictable.  
Whether or not they *should,* users do not always process every dialog 
that comes on screen.  Indeed, many users will not even *see* them, 
depending on where the dialog pops up and where their attention is 
focused at the time.

Even more important than the dialog itself, the *result* needs to be 
consistent and predictable.  If a user sends two messages and one 
message gets through fine and the next does not, either because the 
recipient can't receive HTML *OR* because formatting was auto-magically 
stripped away in an effort to meet the lowest common denominator, that 
user will be confused, irritated, even angry.  If the interface does not make 
clear what all the options are and why one would be chosen over the other 
and present that same choice every time and in the same manner, then 
the interface has failed.  It will not help them understand what went wrong 
or what variables might have changed.  It will not help them understand 
what the right choice is and why.  It will not help them make a better 
choice next time.

Creating a special case that says, in essence, "you have created a 
special-case e-mail which can be somewhat safely converted to a 
more-widely accepted format, though it may not come out looking exactly 
like you sent it and it may not be necessary to convert it at all" is not 
helpful.  It complicates the matter unnecessarily and does not help the 
user understand why this particular special-case e-mail can be converted 
nor what the converted e-mail will actually look like.

Therefore, I am recommending that, as Matthew and Phil have both said 
already, we have a single dialog, with the same default which is tuned for 
the best success for the majority of users.  The lowest common  
denominator, must support every last client in the default setting approach 
is not useful or practical (users will rarely switch ON a feature they're not 
already using, but they will turn OFF features that cause conflicts).

(Oh, and these recommendations are far more than just polish; they pretty 
much directly contradict the behavior you're advocating.  UI is rarely just a 
surface-level issue; it involves behavior, workflow, and structure.  If this is 
not the forum to suggest solutions to issues posted here, where exactly 
do you recommend I go to reach a consensus before I am permitted to 
suggest alternatives to your demands?)

    
    

    
  
> I now see that this is entirely a personal issue for you and has little to do
> with "* a lot* of complaints and problems."

NO. I fight for plaintext *only* because it caused "*a lot* of complaints and
problems". Personally, structural HTML in email is fine with me.

> Back to the original point, *MOST* users don't care *what* format they're 
> sending.  MOST users just want to send their mail and be done with it.

But user *do* care in which format they *recieve* msgs.

The result of that is that the software of the recipient has to care. That's
what I implemented (partly).

> If the interface does not make 
> clear what all the options are and why one would be chosen over the other

The interface implemented with this fix does this.

> present that same choice every time

that would be wrong, becauseu the right choice chanegs depending on certain
variables (which we check *and* explain to the user).

> I am recommending that [...] we have a single dialog, with the same default
> which is tuned for the best success for the majority of users

... and thus "Plaintext Only".

> where exactly do you recommend I go to reach a consensus

The newsgroup n.p.m.mail-news.

    
    

    
  
Corrections:

> I fight for plaintext *only* because

The reason why I fight for "Plaintext Only" is that ...

> the software of the recipient

s/recipient/sender

    
    

    
  
>NO. I fight for plaintext *only* because it caused "*a lot* of complaints 
>and problems". Personally, structural HTML in email is fine with me.

If you would be so kind as to provide some evidence of such.  The 
mail-news messages contained only your opinion and no supporting 
evidence.

>But user *do* care in which format they *recieve* msgs.
>The result of that is that the software of the recipient has to care. That's
>what I implemented (partly).

No, it only matters that it *works.* What format it's in is irrelevant.

>> If the interface does not make clear what all the options are and why 
>> one would be chosen over the other
> The interface implemented with this fix does this.

To you, perhaps, but then you have the advantage of having written it and 
already understanding what it does and why.  You've already leapt over the 
part where the user has to understand what all these formats are and why 
they need to care.  The truth is, they shouldn't need to understand or care.



>> present that same choice every time
>that would be wrong, becauseu the right choice chanegs depending on 
>certain variables (which we check *and* explain to the user).

NO.  That's what I've been trying to tell you: the "right" choice does NOT 
change because there is NO RIGHT CHOICE.  You're making the 
assumption that because YOU want the lowest common denominator 
option that everyone SHOULD want the same option.  That's simply not 
true.  In fact, the large majority of users would rather not ever see this 
dialog or ever have to concern themselves that there are several formats 
of e-mail and that they are not entirely compatible (which is OUR problem, 
not theirs).

>> I am recommending that [...] we have a single dialog, with the same 
>> default which is tuned for the best success for the majority of users
>... and thus "Plaintext Only".

Perhaps I should rephrase: the most full-featured, richest, most 
successful experience for the majority of users; the 90% that use mail 
clients that can handle HTML and/or multi-part mime.

>> where exactly do you recommend I go to reach a consensus
>The newsgroup n.p.m.mail-news.

Ah, right.  No discussion allowed here.  Heaven forbid I should suggest 
something in a bug that I haven't first discussed thoroughly in the 
newsgroups.  Good thinking.  Better get rid of this "Additional Comments" 
feature, too.

    
    

    
  
> If you would be so kind as to provide some evidence of such.

John?

> No, it only matters that it *works.* What format it's in is irrelevant.

The format is relevant for the question if it works. Some keywords: Palm, blind,
preference of a mail client != big 5 (Mozilla, 2xMS, Eudora, Lotus).

> the 90% that use mail 
> clients that can handle HTML and/or multi-part mime.

And want about the rest? 10% are at least 30 millions. Shouldn't they be able to
read their mail? Is there any point to send a mail the recipient cannot read?

> >The newsgroup n.p.m.mail-news.
> Ah, right.  No discussion allowed here. 

Exactly, not in my bugs, not in this extend. Bugzilla is supposed to track work.
I will not discuss about HTML vs. plaintext mail in this 5-line textarea. (And
especially because we had this discussion already.)

    
    

    
  
[Ben said that HTML causes problems, Brendan asked for cites, Ben referred it to me]

The reason that the GNKSA has a requirement that HTML not be the default, and 
that the program can not SET it to the default in all cases, is because when Netscape
did this in an earlier version there was a rash of such post, followed immediately by
a rash of objections (flames for those less polite).  This goes on to this day, although
most of the people "complaining" are no longer flaming, and instead are just "informing".

I did a DN search for "please post html plain*" (order doesn't count) and the first 2
different subjects were request to post in plain text (to be a be a bit more precise,
the first 2 non-faq subjects.  The FAQ, which was for alt.html, included instructions
saying that you should only post in plain text).

OK, on to my own suggestion -- I'm not familiar with what is possible for prefs,
but if possible I would suggest (a) setting the default to "send plain text, intelligently
converted" (however that should be worded) and (b) if that is not possible, leave it
set as the default radio button, BUT *disable it* so that the user has to pick one of the other
options before the "OK" button is enabled.  I have seen this in other programs, although I 
can't give you any examples off hand.

    
    

    
  
This bug won't help us pass the GNKSA, because the dialog in question only 
applies if the user already has `Ask Me' set in their prefs anyway. (We can pass 
the GNKSA if we *always* ask the user when they post a richly formatted message 
to a Usenet group; asking them would be eliciting `explicit user demand'.)

What this bug would be doing is turning two situations into three. Before, we 
had:
* message contains no rich formatting
  --> it gets converted to plain text (bug 28420)
* message contains rich formatting
  --> ask the user, with the default as `both'.

Not perfect, but relatively simple.

But under the regime proposed in this bug, we would have three different 
possibilities:
* message contains no rich formatting
  --> it gets converted to plain text
* message contains rich formatting which is, in the opinion of Ben Bucksch,
  convertible to plain text without `data loss'
  --> ask the user, with the default as `text only'
* message contains rich formatting which is, in the opinion of Ben Bucksch, not
  convertible to plain text without `data loss'
  --> ask the user, with the default as `both text and HTML'.

To make things worse, the second and third situations would be presented in 
similar but not identical ways to the user (through a dialog which had the same 
options, but different defaults).

The second situation should not exist. If you know what to do with the message, 
then just send it. If you don't know what to do, ask the user. Halfway measures 
like changing the default will confuse users, cause errors, and irritate people 
as they wonder whether the program is asking questions when it really knows the 
answers all along.

> I did a DN search for "please post html plain*" (order doesn't count) and the
> first 2 different subjects were request to post in plain text

Well of course. Firstly, the search you did was of Usenet, and not of e-mail. And 
secondly, groups where HTML is not objected to are hardly going to feature 
messages saying `please post in HTML', are they.

This bug needs a WONTFIX from someone. And that someone obviously isn't going to 
be the reporter/assignee; because one hand the one hand he is demanding that 
those of us who disapprove (Phil, Brendan, and myself) form a `consensus or at 
least a majority', while on the other hand he is recommending `to review and 
checkin the patch' when he doesn't have either a consensus *or* a majority.


    
    

    
  
> This bug won't help us pass the GNKSA

Please note that John *made* the GNKSA evaluations in the past.

> This bug needs a WONTFIX from someone.

This bug was here a long time, and several people saw it, and we discussed about
it *before* I implemented it. Phil expressed a concern, which I, from my POV,
addressed in the implementation. After a bug is implemented is certainly a bad
time to mark it WONTFIX.

Is there any reason to object to change the *text* of the dialog, telling the
user that we *can* convert to plaintext? The reason why we pop up the dialog
might be something as easy to convert as a list or an indention, and, I think,
we should tell the user so.

I don't see any valid objection to change at least the text. If we should change
the text, we should check this patch in and discuss the details (as listed in an
earlier comment of mine) on a newsgroup.

    
    

    
  
Well, Ben Bucksch says we're not allowed to discuss this any more since 
it's his bug, and that since he's already fixed it, we're not allowed to do 
anything but throw out our own opinions and let him check in his fix.  
However, since it seems there is large disagreement with the fix, I'm 
marking this WONTFIX.  From a UI perspective, it's just not a good idea.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX

    
    

    
  
Again: I don't see a valid objection to change the text of the dialog.
REOPENing.

If you want to discuss this, then
- be sure to *read* the thread about plaintext vs. HTML mail (not just the
headers)
- discuss the details on .mailnews.

Until then, please let's review it and check in the patch. It already starts
bitrooting.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

    
  
Status: REOPENED → ASSIGNED

    
    

    
  
I *did* read the messages.  All of them.  But since you're apparently 
unwilling to read what *I'm* saying, I'm withdrawing from this rather 
one-sided discussion.  You just go ahead and do whatever you want.

    
    

    
  
I have to apologize to Ben.  I ok'd doing this when I clearly hadn't thought 
through this as much as everyone else who has commented on both sides of the 
issue.

My opinion is that we shouldn't change the default.  Memory of the default is 
very important and if we decide that we want to make a recommendation I'd rather 
see it some other way such as mpt suggested.

I also think the default should be plaintext and html.  I'll prepare to be 
flamed when I write this, but although I have sympathy for those who can't 
receive html, if we're only alienating 10% of possible users then I don't think 
that's such a bad thing. (plus we are sending it in both in this situation).  I 
don't think we should be defaulting anyone to plain text.  The user made the 
choice to use html compose (and even if they didn't because it's the default, 
they made the choice to use html).  This dialog is their warning that some may 
not be able to receive in html.

So, although I don't expect my comments to necessarily stop this debate I would 
like to see the following things happen:

1.  No changing of the default
2.  Default to html and plain text
3.  If we believe that users might be sending out html blindly, come up with 
better wording to make users understand why they are being presented with the 
ask me dialog.

    
    

    
  
<rant>
*sigh* The old debate does start up again. And I though, we had a solution that
is acceptable for all. Now, the plain text users are the loosers again. You'd
think, an open source project showed a but more common sense.
</rant>

Reiterating: I don't see any objections to change the text and possibly add a
"recommended" behind one option, without changing the default. So, if somebody
has objections to that, tell them now, or I will change the patch that way, so
the stuff can be checked in. The bulk of the patch is the recognition of
non-convertable tags, so we should really get this in. Everything else can be
discussed on .mail-news, and it requires only small changes to the code.

    
    

    
  
Not sure exactly what you're proposing Ben -- could you cite comments in the bug
or newsgroup which describe your current proposal? Bdonohoe proposed this, which
seems painless enough, modulo some wordsmithing:

> Mozilla can convert your message to plain text.  This will make it easier for
> older mail programs to read your message, but some text formatting may
> be lost.
>
> (O) Send plain text and HTML.
> ( ) Send HTML only.
> ( ) Send plain text only.


    
    

    
  
Phil, the current implementation recognizes that the msg only contains
"convertable" (see at the very beginning for definition) elements and reflects
that in the UI. It does so by
1. Adding some informational text to the dialog, which is either
  1. "Your message can be converted to plaintext without loosing important
information. However, the plaintext version might look different from what you
saw in the composer." or
  2. "However, you used formatting that cannot be converted to plaintext.",
  depending on the case. (We should finetune the wording later.)
2. Setting the default selection to plaintext in the first case and not setting
any in the second.
I will attach screenshots.

My proposal is to
1. let the text part (1.) as-is,
2. add a " (recommended)" to the label of the plaintext option in case the msg
is "convertable", and
3. set no default at all until we resolved this. I refuse to set the option to
HTML+plaintext.

I will modify the infrastructure to easily allow any of the suggestions (other
than WONTFIX, of course) to be implemented.

I hope we can reach consensus.

    
    

    
  
I think the current implementation is good enough, but if you think it's
important to add "recommended" on text/plain in the convertable case, I don't
have a strong objection to that. I do have a strong objection to having a
radiogroup without a selected choice -- that's really bad UI.

    
    

    
  
> if you think it's
> important to add "recommended" on text/plain in the convertable case

Yes, I do think that this is important, this was the whole point of this bug.

> I do have a strong objection to having a
> radiogroup without a selected choice -- that's really bad UI.

I agree that this is bad UI, but it is even worse to misguide the user (while it
depends on the POV, what the "misguiding" option is).

I don't know what to do about that. I cannot alter the default, I must set a
default, we (Netscape + Matthew vs. the rest of the open source world) cannot
agree on the default. I don't think, we can resolve this question here. The only
question is what to do *for now* until we resolved it.

    
    

    
  
*** Bug 28735 has been marked as a duplicate of this bug. ***

    
    

    
  
I have the changes mostly ready, but are blocked by an XUL bug. I change the
text using JS, and the object indeed picks up the change, but the dialog doesn't
reflect it. If somebody knows a workaroung, let me know.

Changing SUMMARY from "" to "" in order to reflect discussion. Will file a new
bug about setting the default, if we (the Mozilla community, including Netscape)
decided that that's a good idea.
Summary: Set default for askSendFormatDialog to plaintext, if reasonable → Recommend plaintext, if reasonable

    
    

    
  
*** Bug 46747 has been marked as a duplicate of this bug. ***

    
    

    
  
I have a workaround for the problem. Not pretty code, but works.

I'll try to add an icon with green/yellow/red background, depending on the case.
Would that change the problem of changing the default?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix, version 8
        — 
          — Splinter Review
      

    


  

    
    

    
  
The default doesn't change anymore (it still can, if you change one constant in
the source), but a "recommended" is added behind the recommended option, if one
exists. I sat the default to plaintext, but it is easily changeable.

Added a new mode: Convertable without changing the look (much), e.g. only
indention, <ol> etc.. If we decide so, we can skip the dialog completely in this
case with only a minor code change. I had to rework most of the code to make
that possible. It should be fairly flexible now.

Images didn't work :-(. I'm tried of debugging XUL, so I just commented it out
for now. I'll attach the images themselves later.

ducarroz, please review the latest version. I want to get this in now.

    
    

    
  
good job. r=ducarroz

    
  
Keywords: review → approval

    
    

    
  
A big patch, which I can only scan for misspellings, style glitches, etc.  Here
they are:

- Convertible is misspelled throughout.
- IDL style should be interCaps, not InterCaps, for attributes and methods, and
  ALL_CAPS_WITH_UNDERSCORES for constants (XPIDL style matches Java style, and
  JS style too).  The C++ bindings get capitalized to InterCaps, so there's no
  change required to .cpp files.
- Indentation looks wrong in the patch in function Startup -- are hard tabs
  being used?  Please expand them per the Emacs modeline comment on the first
  line of the file (fix that modeline if its c-basic-offset is wrong, should
  be 4 rather than 2 for this code, from the looks of it).
- If you're not too tired, could you find out why the images don't work, or
  at least file a bug and cite its number in this bug?  Thanks.
- In the convertableAltering.label (sic), "loosing" should be "losing" -- check
  for other such wrong-word errors throughout.
- Do I understand correctly: class="txt..." or class='"txt...' on an HTML tag is
  enough to identify it as coming from Mozilla compose?

/be

    
    

    
  
> - Convertible is misspelled throughout.

Corrected.

> - IDL style should be interCaps, not InterCaps, for attributes and methods,
> and ALL_CAPS_WITH_UNDERSCORES for constants (XPIDL style matches Java style,
> and JS style too).  The C++ bindings get capitalized to InterCaps, so there's
> no change required to .cpp files.

Corrected for the method I added. However, *all* methods in that interface were
capitalized, I'm not going to change that.

> - Indentation looks wrong in the patch in function Startup -- are hard tabs
>   being used?  Please expand them per the Emacs modeline comment on the first
>   line of the file (fix that modeline if its c-basic-offset is wrong, should
>   be 4 rather than 2 for this code, from the looks of it).

The modeline has "4". This bugged me as well, but I was unable to find out
what's wrong. IIRC, I tried both spaces and tabs, but it was messed it up in
both cases.

> - If you're not too tired, could you find out why the images don't work, or
>   at least file a bug and cite its number in this bug?  Thanks.

Bug 49584.

> - In the convertableAltering.label (sic), "loosing" should be "losing" --

Corrected.

> check for other such wrong-word errors throughout.

I can't, I'm not a native english speaker.

> - Do I understand correctly: class="txt..." or class='"txt...' on an HTML tag
> is enough to identify it as coming from Mozilla compose?

d/compose

I don't think, many HTML mail authors/generators will use a class (attribute)
starting with "txt".

(BTW: This is in an #ifdef 0)

    
    

    
  
cc brendan to a= new patch.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix, version 9
        — 
          — Splinter Review
      

    


  

    
    

    
  
I read the latest patch and have these suggestions:

* <!ENTITY windowTitle.label "Message Format">
* <!ENTITY recipient.label "One or more of the recipients of this message are 
not recorded in your address book as being able to read richly formatted (HTML) 
mail.">
* <!ENTITY convertibleYes.label "The message can be converted to plain text 
without any loss of information.">
* <!ENTITY convertibleAltering.label "The message can be converted to plain 
text with only minor alterations.">
* <!ENTITY convertibleNo.label "In the message you used formatting which 
Mozilla cannot convert to plain text.">
* <!ENTITY question.label "How do you want to send the message?">
* <!ENTITY plainTextAndHtml.label "As both plain text and HTML">
* <!ENTITY plainTextOnly.label "As plain text only">
* <!ENTITY htmlOnly.label "As HTML only">
* <!ENTITY plainTextAndHtmlRecommended.label "As both plain text and HTML 
(recommended)">
* <!ENTITY plainTextOnlyRecommended.label "As plain text only (recommended)">
* <!ENTITY htmlOnlyRecommended.label "As HTML only (recommended)">
* <!ENTITY recommended.label "(recommended)">

(Why do you need all of those last three? Why not just the first two, or just 
the last one?)

<!ENTITY dontSend.label "Cancel">

(Not `Don't Send', because it returns you to the message and you *can* send it 
later)

Non-UI text corrections (meaning that you don't have to worry about them:-) ...
* `Will loose data:' --> `Will lose data:'
* `visual formating' --> `visual formatting'
* `really affect the formatting' --> `really affects the formatting'
* `recommondation' --> `recommendation' (twice)
* `<!--<deck' ... Are XML comments allowed to contain < and > characters?
* `<!-- Hack: box and html are workarounds for bug  -->' (which bug?)
* `that ask the user' --> `that asks the user'
* `an anchore tag if the link is the same than the text'
  -->
  `a link if the linked text is just the link URL'
* `recognite' --> `recognize'

Hope this helps ...

    
    

    
  
Re images:
I found another, much better way to add an image: via CSS. Works! Will attach
images and patch for themes separately.
(BTW: I have to change 15 (!) files to add 1 image!)

Matthew,
> (Why do you need all of those last three? Why not just the first two, or just 
> the last one?)

This is part of the workaround for what seems to be an XUL bug (label doesn't
switch). The first three are the real version and the last one is the
workaround.

> <!ENTITY dontSend.label "Cancel">

Changed.

> `<!--<deck' ... Are XML comments allowed to contain < and > characters?

Yes. <http://www.w3.org/TR/REC-xml#sec-comments>

In comments:
> * `really affect the formatting' --> `really affects the formatting'

In "unified" or "context" diffs, lines starting with "-" are *removed* from the
source.

> * `<!-- Hack: box and html are workarounds for bug  -->' (which bug?)

Bug 49623. :)

[other comments]

Corrected or Changed

    
    

    
  

      
      
      
      

        Attached file
          
        Fix, version 10, Icons
        — 
      

    


  

    
    

    
  
ducarroz, can you please r= the new changes (mostly the images), please?

Do I have to add new skin files to Mac project files or are the MANIFEST files
enough? I can't find "macbuild" dirs in mozilla/themes.

    
    

    
  
R=ducarroz
MANIFEST files are enought. 

Sorry for the delay, I was (and still) sick...


    
    

    
  
> R=ducarroz

a=brendan?

> Sorry for the delay, I was (and still) sick...

np, thanks for reviewing while you're sick!


    
    

    
  
> Corrected for the method I added. However, *all* methods in that interface
> were capitalized, I'm not going to change that.

So if no JS yet calls any of these methods, you can safely uncapitalize all of
them, because xpidl will capitalize the C++ bindings.  If you're in a generous
mood, go for it.

You mentioned #if 0'd code -- how long do you intend any such to live?

a=brendan@mozilla.org, but don't be shy about cleaning up the above.

/be

    
    

    
  
Checked in!


> So if no JS yet calls any of these methods

Most of them are called from JS.

> You mentioned #if 0'd code -- how long do you intend any such to live?

I have no idea, but I have a bug about it: bug 44552.

> - Indentation looks wrong in the patch

I have still no idea why it looks so odd in the patch, but bonsai
<http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/mailnews/compose/resources/content&command=DIFF_FRAMESET&file=askSendFormat.js&rev1=1.6&rev2=1.7&root=/cvsroot>
likes my indention.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
If Netscape really wants to default to multiüart/alternative (although I don't
hope it will), it just has to change |defaultElement|
<http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/askSendFormat.js#13>.
Target Milestone: M17 → M18

    
    

    
  
I'm posting here because my original bug report was marked as a duplicate of a
duplicate of this bug.

I notice that the HTML Mail Question dialog has improved to the extent that it
is now completely visible. However unlike your screenshot (which was probably
not Windows, in case that is relavent) it has expanded to the width of the
screen, which is strange as the right half of the dialog has not content!

    
    

    
  
Neil, please grab a nightly from taday (should be online at ~10-12am PDT) and
retest. Also see bug 50217. If bug still appears, please attach a screenshot.

    
    

    
  
changing qa 
QA Contact: lchiang → esther
Product: MailNews → Core
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: