OK; judgement accepted. What follows is just a couple of points I feel 
worth making for the record (with a view to your point about future 
readers) to clarify, as it seems to be necessary, what I was really 
trying to say with this ticket. You can therefore stop reading here if 
you desire.
It was never really about transport, though I'll admit my wording 
didn't help: that one word "anti-socially" mischaracterised the 
message hugely, I now see (and my second post was largely *me* being 
combative and getting off the original point).

My true focus was usability for me, the person composing. If, for 
whatever reason, that textarea is rendered wider than your UI team 
intended (by making the compose popup window the size it is), then I 
am typing lines so long that usability suffers, for me, right there 
and then. I can't read it back to myself comfortably.
Correct, it's a UI issue. It pertains, however, to parts of the UI 
that you do have at least partial control over. That, I assert, is why 
your UI code pops the compose window at this particular width: because 
we (mostly) don't like writing text in lines the full width of our 
desktop screen.

Where the webmaster has control is in hacking on your UI code if that 
scenario is likely among his users; this is what I currently do, by 
adding the CSS max-width declaration to the textarea.

Where the user has control (assuming they fully control the browser) 
is choosing whether or not popup dimensions in javascript are 
respected (which is a global setting so it affects their use of every 
site); or, as is the case with Firefox and IE at least, manually 
resizing the textarea to a bearable width.

I chose max-width because it is unobtrusive: users who don't overrule 
your UI team's chosen dimensions for the popup will never know the 
difference, nor will people with a screen that's narrower than that 
width (eg smartphone users demanding the desktop UI for whatever 
reason). Only if they have a virtually microscopic default font-size 
can I see anyone else being affected -- and if you like text that 
small, you might want the textarea a little narrower anyway...!

So that's what I was getting at. Where *you* have control is in doing 
what the webmaster does above, to extend your UI choices, which of 
course are made in the name of the best usability for most/all Horde 
users, to a few corner cases you otherwise don't reach. Transport, 
recipient-end display: not part of it.

If I could have predicted a reason for rejection of this ticket, it 
would have been that the corner-case was too obscure to be worthy of 
the work; to which I'd reply that I think there might be quite a few 
of us who don't like giving all websites the power to hit us with any 
size of popup they like (I'm sure in your years you have seen that 
power abused often enough by the bad guys). Nevertheless, if that's 
the basis of the rejection, then I'm okay with it.

I wasn't being combative.  I was trying to explain the difference, as 
I understand it, between transport and presentation.  To make my 
point, I tend to use a lot of emphasis (must be my teaching background).

Apologies if that was too direct of a response.  Unfortunately, as the 
time goes on, I have less and less time to devote to the project, so I 
find that being direct and clear in responses saves a lot of time on 
the back end.  It also is a more useful response to those who later 
view the ticket and might have the same issues.

So what I get out of this is that this is a UI issue.  I'm not 
convinced that any sort of action is necessary on our end.  Locally, 
you can always use CSS to size the window as you see fit.  Just 
remember that what you see on the screen is not necessarily what will 
be seen on the receiving end, so that should not be the focus of any 
UI change.

Rather unnecessarily combative response there Michael, if I may say 
so. I'll admit (and duly apologise for) my knowledge of email being 
somewhat superficial. I've used it for a bit more than 15 years, but I 
haven't been as deeply involved in its implementation as I currently 
necessarily find myself. That obviously makes me at times reliant on 
my observations of how things are usually done, which I call 
conventions (nobody mentioned standards).

I *have* been berated for my lines of text being too long, and I've 
seen it happen to others. Text content is *not* routinely flowed in 
this bold new world: Did you ever see a README, or a code file, that 
didn't restrict line-width to somewhere around 80char? Look at your 
own reply right here, on the Horde platform: I see plenty of inserted 
line-breaks. More to the point, why is the Imp compose *window* chosen 
to be the width it is?

If you prefer, let's treat it purely as an ergonomic, or usability 
matter. I'll assert that the basis for the compose window's width is 
that most people find it harder to read text whose lines are too long. 
The limit of personal comfort/acuity is different for everyone, but 
there are popular *conventions* across various collaborative platforms 
that peg it at 80char, 78char, sometimes even 60char. I've always 
considered it good general netiquette to conform to the 80char 
convention, and those of us who like to read what we write before 
hitting Send (perhaps this is also a relic of years ago?) find the 
width of horde's window very sensible for this reason.

I'm very appreciative of the work you do on Horde, and the personal 
help you've given me as I'm sure you're very busy with it. I certainly 
have no pretensions of this ticket being of anything other than very 
low priority; but there's no need to jump down people's throats.

The message width in the compose screen is completely irrelevant.   
Especially in light of flowed text, in which it is the *recipient's* 
choice on how to wrap the message.  Not to mention that the width of 
the textarea has nothing to do with linebreaks.  Unless a user 
manually enters a linebreak after every line, textarea input will be 
sent in a long unbroken line.

And there is no such thing as an 80 column email display standard.   
There's a 78 column *sending* standard.  But this long ago became 
obsolete for display purposes when flowed formatting was introduced 
(~15 years), which eliminated this technical restriction from 
affecting the display of the content.

In Firefox (and probably other tabbed browsers), popup windows can be 
diverted into a tab of the existing window, instead of the intended 
sized new window.

Because the compose textarea takes 100% width, this makes its width 
potentially *anti-socially* large if opened in this manner (or if 
adjusted manually by the user).

I suggest that a max-width CSS attribute be added to 
/imp/themes/default/dynamic/screen.css in the definition of 
#composeMessage, to prevent the textarea (by default, at least) from 
being too wide.

I peg it at about 55em to match the intended width, which also works 
out to about the conventional 80-char limit preferred by many 
listadmins and so forth ;)

Another approach might be to put a max-width on the whole page body, 
but I lack the CSS wizardry to know what that might break elsewhere.