Open Bug 71110 Opened 24 years ago Updated 13 years ago

need pref to set message view pane width separate from window width

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: kcha-ns-yka, Unassigned)

References

(Blocks 1 open bug)

Details

With a high screen resolution and a fairly wide 3-pane window (to get as much
info in the threadpane as possible), format=flowed plain text (and html) mail
can have very long lines, making reading difficult. A means to set the max-width
for the message view pane is needed, to make these messages more readable
without sacrificing content in the thread pane. IMO, this is a usability issue.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Should be easy to implement via CSS. Only problem: It must not apply to the
standalone msg window.
I agree that it is a usability *problem*, not an enhancement.
Severity: enhancement → normal
Can't you just resize the window to be smaller?
He mentioned in the news group that he wanted a wide thread pane so making the
window less wide doesn't work.

I would like a "margin" icon at the top of the display window which you can drag
to wherever you want the right margin in the display. Wonder if it could be done
by a splitter and some cute CSS which makes the splitter, and the part to the
right of the splitter look as a empty part of the message window...
Summary: need pref to set message view pane width separate from window width → need pref to set message view pane width separate from window width (for format=flowed, esp)
*** Bug 72601 has been marked as a duplicate of this bug. ***
*** Bug 130007 has been marked as a duplicate of this bug. ***
I agree with Daniel.

For a quick and dirty hack, we could probably output some CSS that limits to a
certain width, in the HTML that the f=f converter generates. The width would
come from a (hidden?) pref.
In a world where format=flowed was only set in messages where the sender had 
explicitly enabled this, then it could perhaps be argued that reflowing the 
message lines in the recipient client should be on by default.  But this would 
only be the case if it could be reasonably assumed that the recipient person 
really wanted the text spread all over the width of their window.  With wide 
screens and the loss of readability beyond 60 or 70 columns, I argue that this 
cannot be assumed.

Unfortunately, for many people, format=flowed is on be default in their client 
and they have no understanding of this and its implications for how their 
message is viewed.  Furthermore, they may have no actual or obvious way of 
turning it off.   This unfortunate situation is further reason to make the 
interpretation of format=flowed off by default, but I don't think any further 
justification is required.


I think the interpretation of format=flowed should be off by default.  If it is 
turned on, which should be easy via a GUI user option, then the user should be 
able to set some limit to the width of such reflowing, otherwise, this inhibits 
them from using the wider windows which might be most convenient for them.


Email clients should by default support plain text communication, where every 
single character the sender writes, including the exact position of each 
character, is reproduced precisely, without adornment, to the recipient, 
exactly as the sender saw on his or her screen when they wrote it.

To disagree with this is to have a fascist attitude to how other people 
communicate.  It is to say that the automagic, nifty, alterations to messages 
you like should be forced on everyone - or that some things, such as 
changes to the "format" or "layout" (implicitly to some people, not part of 
the "content" of the message) can safely be assumed to be unimportant to the 
sender and recipient. 

For an extended version of my thoughts on such things, please see Bug 86607 
which concerns turning "> " into vertical bars.


  
Format-flowed is a good example of something which is potentially useful which 
can alter the layout of the message as seen by the recipient, without the sender 
ever knowing.  Sometimes, the layout of the message is important - its not just 
a cosmetic matter.  Even if it was "cosmetic", there is no reason why "cosmetic" 
alterations should be forced on everyone by default?   I think that some 
programmers and HTML fans draw unrealistic distinctions between the "content" of 
 a message and its formatting.  Sometimes, the formatting is a vital part of the 
content - such as when writing tables of text, diagrams, poetry etc., and so 
this should never be altered by default arrangements by either the sending or 
recieving software.


It should not be necessary to demonstrate circumstances when such unwanted by 
the sender, unseen by the sender, alterations of their message are likely to be 
a problem.  Why should people have to argue for leaving messages alone?  There's 
no good reason.  Its not good enough for someone other than the sender to decide 
that "layout" or "format" is not part of their message.  Often enough, it is 
an important part of their communication.

If we want super-fancy automagic things popping up and doing smarty-pants 
nifties by default, we will use software from the Evil Empire.  Please keep 
Mozilla straightforward and clean.

 - Robin    http://www.firstpr.com.au

Robin Whittle, please stop spamming all bugs with "format=flowed" in their name
with your extensive, copy&paste political statements, which are totally offtopic
and wrong.

> the recipient person really wanted the text spread all over the width of their
> window.  With wide screens and the loss of readability beyond 60 or 70 columns,
> I argue that this cannot be assumed.

Did you even read this bug? Changing that is all which this bug is about.
I am not spamming or discussing politics.  I support the proposal in this bug to 
make the width of reflowing format=flowed messages a user-selectable option, 
with a visible slider.

I am pointing out that the current situation of format=flowed being on for all 
sent messages, without any user option (other than hand editing a prefs file) 
means that lots of messages are being sent with format=flowed when their author 
firstly had no knowledge of this and its implications for the recipient, and 
secondly if they did know about it, would want this not to happen to their 
messages.

If the default for sending messages was not to send with format=flowed, and if 
there was a GUI option for turning it on, with appropriate explanatory text, 
then the number of messages which have it on will be greatly reduced, since only 
those people who understand this and actively choose it will be sending messages 
with it turned on.

This would reduce the need for this user-selectable width of reflowing, because 
it would only be a subset of messages which enable it.  The remainder of plain 
text messages would be perfectly readable and printable, displayed with lines of 
up to 72 characters or whatever number of characters the user consciously chose. 
 Some people do chose to write with 50 column margins, and I think that's fine.  
Its perfectly readable.  (Email clients which send each paragraph as one long 
line are a menace!)

If you want to read more of my plea for Mozilla to support straighforward email 
commucation without enhancement / transformation / mangling, please see 
Bug 8986.

   - Robin
Oops.  Scratch that last paragraph.

If you want to read more of my plea for Mozilla to support straightforward email 
communication without enhancement / transformation / mangling, please see: 

  http://bugzilla.mozilla.org/show_bug.cgi?id=86607
  [RFE] UI option for disabling format=flowed

  http://bugzilla.mozilla.org/show_bug.cgi?id=88986
  Use > instead of grey bar for format=flowed quotes, optionally
Robis, this is a bug or necessary enhancement with or without format=flowed (on
the sending or recieving side). We do recieve real plaintext messages with very
long lines (one line per paragraph), which will wrap to window width. HTML
messages wrap to window width as well. This means that this bug is independant
of f=f, f=f is just *one* case where is appears.
That's why your argumentation is totally offtopic. It is spam, because you
additionally posted it (via copy&paste) in several bugs.
I'd like to support the views of the gentleman who is accused of "spamming".  
He raises a VERY important point: the writer should be able to have complete 
faith that his message is being seen by the recipient EXACTLY as he wrote and 
formatted it. This goes for plain text as well as HTML.  My own pet peeve is 
the absence of a right margin carriage-return setting.  I want my lines to 
break after 50 or 70 or however many characters I choose - in both plain text 
AND HTML ESPECIALLY.  Mozilla's is not the only email client missing this 
feature; it would be nice to see Mozilla take the lead and show that the open-
source concept is democratic and more responsive to people's real needs.
Steve Notis wrote:
> I want my lines to break after 50 or 70 or however many characters I choose

But Mozilla does this already. Standard is approx. 72 characters per line.
Mozilla breaks lines just fine. Format=Flowed is a way of *displaying* emails,
what you see while composing is sent out that way, the *only* thing Mozilla (or
any other f=f mailer does) is add an empty space at the end of each line so that
f=f capable mailers can make use of f=f. Just check the source of an f=f email,
the line breaks are there.
I think many people just don't understand what f=f is exactly.
*** Bug 145899 has been marked as a duplicate of this bug. ***
Mozilla posts stand out in the newsgroups that I frequent becuase they are the
only ones that are format=flowed.

It really does not matter how supperior that some feel that the format is, the
composer of a message should have the option to compose and send their message
in a pure plain text mode.

The big problem with format flowed is that I hit the carriage return key by
habbit when I see the cursor approaching the margin.  When the lines are edited,
they autowrap.

So while the e-mail or the news posting looks properly formatted when I send it,
it looks like garbage when it is read by a newsreader that understands
format=flowed.

Microsoft Exchange users are having a similar problem trying to get "Quoted
Printable" disabled.

I appologize, I got the bug numbers and windows mixed up.  My above comments
were for a different bug # 86607
See comment 9 and 12.
Whiteboard: This bug has nothing to do with format=flowed
Summary: need pref to set message view pane width separate from window width (for format=flowed, esp) → need pref to set message view pane width separate from window width
While from a narrow technical perspective this bug has nothing to do with 
Format=flowed, from a user perspective, it certainly does.  A lot of the reason 
why people want a message view pane width control is that an increasing number 
of email and Usenet messages have "Format=flowed" turned on.   

To the extent that this is occurring due to the default, hard to change, or 
uchangeable settings in the client (Mozilla, MS Outlook Express etc.) causing 
people to send messages with "Format-flowed" when they don't really want to, or 
when they do not know it is happening and do not know the trouble it can cause 
for some recipients, then this bug is related to "Format=flowed" and could be 
made less of a problem by making "Format=flowed" in the client an option - which 
in my view should default to "Off".

But irrespective of the "Format=flowed" or increasing and even more 
pernicious "each paragraph is one long line" nature of messages, it would be 
great to have an easily settable option for the width on-screen line lengths of 
received messages.


Firstly, I strongly agree with comment 8. I actually found this bug because --
once more -- in another bug someone complained (actually off-topic to that bug)
that his setting of line wrapping does not work. Presumably it does, but he does
not see it due to f=f. This bug would solve this.

But let me give a warning opposed to what Ben wrote to the status whiteboard. I
think it really has to do with f=f. Let's look at typical situations to see why:

1) A user sends f=f. So we display endles lines. This bug is about changing that
behavior. Say we agree to use the value set for line wrapping or anything of
that magnitude.

2) A user sends real plain text with a line length longer than the display
length value from 1). If we still display wrap that message we get a sawtooth
pattern of long lines and the leftovers. This MUST NOT happen. It is not an
option to wrap real plain text anywhere before window width.

So I suggest to change back the summary to restrict this to format=flowed
display and remove the whiteboard entry.

pi
> It is not an option to wrap real plain text anywhere before window width.

I disagree, some mailers send one liner per paragraph, and these messages will
be just as hard to read when wrapping at window width as format=flowed messages
are today due to this bug.

You missed a third typical situation: HTML. same problem as with f=f.

Status whiteboard / summary: I was just utterly pissed about the f=f-hating mob,
which copy&pastes endless f=f hateress propaganda in all bugs mentioning f=f,
although explicitly instructed not to do so. I wondered why they hit this bug
(thus the status whiteboard message) until I saw the mention of f=f in the
summary. I just tried to prevent that. Clearning status whiteboard now that f=f
from summary. I hope we won't mention f=f anymore here unless as a way to
reproduce this bug.
Whiteboard: This bug has nothing to do with format=flowed
Ben,

I agree, HTML is also a case where wrapping makes sense.

You mention those bad readers (or users, nevermind) which send long line in real
plain text. Yes, they are out there, but there is nothing a machine can do to
determine if this is the case. So I still think: Do wrap at window width. Don't
do anything else.

So this new additional wrapping should apply only to f=f and HTML. (Don't know
about richt text.)

pi
I've solved this problem for me setting:

.moz-text-flowed {
  max-width: 80ch !important
}

in my "userContent.css".
For HTML I've used:

.moz-text-html {
  max-width: 42em !important
}

Sorry for the spam.
Blocks: 168420
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: esther → message-display
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Dead for six years, closing.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
The actual problem is still there.
And WFM wouldn't be the correct solution anyway!
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
I this this same problem with thunderbird 3.1.10
You need to log in before you can comment on or make changes to this bug.