Tickets :: Comment on [#12802] Limit max width of compose textarea in dynamic view

* Your Email Address
* Spam protection	Enter the letters below: . ..__ .__ . .. . \ /[__)[ __\|\/\|\|_/ \/ [__)[_./\| \|\| \
Comment	> 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.
Attachment
Watch this ticket

Saved Queries