Fri, 10 Apr 2026 10:04:35 +0000 https://bugs.horde.org/ticket/12802 Limit max width of compose textarea in dynamic view 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. Mon, 28 Oct 2013 17:05:44 +0000 https://bugs.horde.org/ticket/12802#t81293 > 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 ;) 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. Mon, 28 Oct 2013 19:15:23 +0000 https://bugs.horde.org/ticket/12802#t81296 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. Tue, 29 Oct 2013 09:40:56 +0000 https://bugs.horde.org/ticket/12802#t81302 > 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 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. Fri, 01 Nov 2013 05:09:51 +0000 https://bugs.horde.org/ticket/12802#t81339 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. > 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). > 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. > 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. 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. Fri, 01 Nov 2013 16:52:35 +0000 https://bugs.horde.org/ticket/12802#t81344