Closed Bug 29557 Opened 25 years ago Closed 25 years ago

Format=flowed messages use <blockquote> style quoting

Categories

(MailNews Core :: MIME, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: phil, Assigned: bratell)

References

Details

Attachments

(1 file)

Using 2000-02-28 build on Windows NT

1. Compose a mail message using the HTML compose window
2. Before sending, use Options | Format | Plain text to set the outgoing 
content-type
3. Send the message
4. Display the message in the Sent folder

Expected: message to be displayed in fixed width font, since the content-type is 
text/plain.

Actual: message is displayed in variable width font, as though content-type had 
been text/html.
Phil,
is the content type precisely "text/plain; format=flowed"? It yes, it is
completely correct to display flowed parts in a variable font.

Not sure, what happens for preformatted parts (compare description of bug
#29369). CCing Daniel for that.

Changing SUMMARY.
Summary: Text/plain messages displayed in variable width font → Preformatted parts of flowed messages displayed in variable width font
> is the content type precisely "text/plain; format=flowed"? 

Yes, of course.

> It yes, it is completely correct to display flowed parts in a variable font.

Yuck. Why? I'd rather use a fixed width font, and soft-wrap the lines. I don't 
see why soft-wrapping implies variable width fonts. In addition, we use 
HTML-style quoting for these messages, and there's no way that's right.
> I don't see why soft-wrapping implies variable width fonts.

Soft-wrapping implies, that usage of variable width fonts is possible (or am I
wrong here?). If possible, variable width fonts should be used, because they are
easier to read.
If you /prefer/ fixed width fonts for plain text mails (of all sorts), you can
set the x-unicode serif font pref to Courier.

> In addition, we use HTML-style quoting for these messages, and there's no
> way that's right.

Why? For format=flowed, we know for sure, that this is a quote, because the
sender marks it as such, so there's no ambiguity.

Inserting "> "s creates problems for nested quotes. You can't remove them
anymore at send to mark the quote as such in format=flowed, and you can't let
the quote flow anymore, which make one of the major advantages of format=flowed
(solving problems with nested quotes) useless.

Enclosing the quote in a "blockquote"-tag also makes formatting per CSS possible
(assuming, that we will have a Mailnews-stylesheet in the future).
I don't see this. The message is displayed according to the 
mail.fixed_width_messages pref as it should be. At least a bug against me before 
christmas said that it should respect that setting.

Could you give an example of a mail that has this problem. (Technically, the 
text is internally wrapped in <tt> when being displayed in a fixed width font. 
Could it be a font problem?)
Daniel, there is no way to differntiate a single flowed line from a preformatted
line, is there? If there isn't, I agree, that the mail.fixed_width_messages pref
should also be honored for format=flowed.
<xmpl>
What do you think about that?:
         _____________
        /    ASCII-   \
        |     art     |
        ---------------
</xmpl>
Ideally, the first line should flow (and displayed in variable width font IMO),
the following lines shouldn't (but displayed in fixed width fonts).
It's impossible to easy to differentiate a single flowed line from a 
preformatted using the standard, otherwise it would be an easy kill. I thought 
alot on that problem as I implemented it the same time as the most hysterical 
ASCII-art debate was filling the mail-news newsgroup.

What I personally would like is a easy way to switch between fixed width and 
proportional width for a single window/message like you can do with a button in 
Eudora. Then there is really no need for displaying messages with a fixed width 
font as default.

I wonder if there is an RFE bug on that yet...
> I wonder if there is an RFE bug on that yet...

Not, that I would know of, but there is bug #20195.
This really belongs in with Daniel. Sorry guy :-)

- rhp
Assignee: rhp → bratell
Some more testing this morning. Here's what I found:

My pref was set to display text/plain messages in variable width font. Don't
know how that got there, and when I changed it in the dialog, the pref didn't
stick. I then changed it by hand in my prefs.js and I now I get fixed width fonts.

However, I still get <blockquote> style quoting, and I still think this is
wrong. Format=flowed is really cool for soft-wrapping, and I'm happy to have it.
But I think we're off the deep end here in trying to make format=flowed look
like text/html, when they're really still text/plain.

Changing the summary to reflect the actual problem. Filed bug 29647 on the pref
not sticking.
Summary: Preformatted parts of flowed messages displayed in variable width font → Format=flowed messages use <blockquote> style quoting
Phil,
IMHO, format=flowed is a hybrid between HTML and plain text: It flows, we know
exactly, what quotes are, and we have some formatting available (with my
changes). You said, you like HTML mail, so I really don't understand your
position here.

Anyway, does anybody have an idea, how to solve the serious technical problems
with nested quotes I mentioned?

The only thing I can think of, is to add a class attribute to the blockquote,
like "<blockquote class=flowed>", and format it differently with a stylesheet.
Phil, I don't know what you want to achieve. With format flowed, we have enough 
information to show the quotes with blockquotes and looking at the two other 
major MUA:s supporting format=flowed, they both use the same method of 
displaying quoting as we do. 

You _could_ use some style to make the thick line look different than today but 
I see no point in that.
> looking at the two other major MUA:s supporting format=flowed, they both use
> the same method of displaying quoting as we do.

Ok, that seems like a good reason to stop where we are. I understand why it's
difficult, but I hoped we had a shot at making display look just like
text/plain, except with the non-quoted portions soft-wrapped. That's what I
wanted to achieve.
As mozilla@bucksch.org said, the only practical way to that would be to include 
an internal type of blockquote to display the mails. You better speak nicely to 
some layout people if you want that to happen. :-)

I'll mark this as WONTFIX for the time being. If someone else has an interest 
in doing something, please reopen the bug and reassign it.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Daniel, you don't need non-standard extensions or Gecko-changes for that.
"class" is HTML 4.0 standard IIRC and you can specify a formatting via CSS. We
only
1. need to insert that attribute in the flowed displayer (mimetpfl.cpp?)
2. let Mailnews use its own stylesheet (I hope, we will do that anyway in the
future)
3. Let the use alter the stylesteet.
If there's demand for it... The default could be not to specify anything for
that in the stylesheet, i.e. status quo.
Maybe I'm dense, but isn't it enough just to wrap the lines beginning with '>'
appropriately for quoted material, and then wrap those sections in a <pre>?
Then, the non-quoted parts get soft-wrapped by layout, and the quoted sections
stay as they were in the original message. I don't see why we need to mess with
<blockquote> at all for text/plain messages.
Phil,
sure, this doesn't influence non-quoted text.
However, we would still have the same problems like we have in plain text today
with parts: fixed lines, i.e. the recipient can't rewrap the text after the
window width or whatever he likes.
*In addition*, we have the following problems:
- If I edit the quote (i.e. to shorten in, what I do often), I have to wrap
manually. Very inconvient.
- Deeply nested quotes create too long lines (due to the many "> "s). Then,
either you send long lines (like 4.x) and risk, that some recipients might have
problems, or you wrap it, which results in very ugly text, e.g.
> > > > > spuozt ot oiszet h it prt eri tpiuerrr rrrrrroisrtoü  przt owzt  to
> > etu üo üortüo ütr.
> > > > > soert woet üutoz uüiu ü t
Here, one (!) mailer in the middle decided to wrap the quote.

In addition, you loose the information, that it was a quote ("> bla" is just
plain text), which is a mess IMO and will propably be a violation of RFC2646.
Phil alerted me to this bug.  For anyone interested in this: I'm expecting to do
some work on the editor InsertAs*Quotation APIs in M15 (see bugs 29699 and
27991) and to detect flowed plaintext insertions at that time.  I will plain on
using <blockquote class=flowed> unless someone tells me otherwise in bug 29699,
and then UE people and end users can twiddle with style to make it look the way
they prefer.  (Personally, I'm fine with it looking like an html quotation, I
think.)

Rewrapping quotations, even plaintext ones, in the editor is something Simon and
I talked about, and in fact I don't think it would be that hard, if someone
wants to file a separate bug to me on that.  My plan is to have the editor never
rewrap non-flowed quoted plaintext unless the user explicitly asks for it.
*** Bug 31045 has been marked as a duplicate of this bug. ***
*** Bug 31045 has been marked as a duplicate of this bug. ***
We should note this in the documentation somewhere.
Keywords: relnote
OK, I couldn't hold back: I implemented the stylesheet change to make the border
black instead of blue for format=flowed. It is intended to be a little toy for
you. Bug #31047 will fix this much more complete.
I looks at CSS2, You can insert content with the ":before"/":after"
pseudo-elements, but I couldn't find a way to match a line or linebreak.
Verified as won't fix.
Status: RESOLVED → VERIFIED
QA Contact: lchiang → pmock
Product: MailNews → Core
Product: Core → MailNews Core
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: