[Tickets #12802] Re: Limit max width of compose textarea in dynamic view
noreply at bugs.horde.org
noreply at bugs.horde.org
Fri Nov 1 16:52:35 UTC 2013
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/12802
------------------------------------------------------------------------------
Ticket | 12802
Updated By | horde at headbank.co.uk
Summary | Limit max width of compose textarea in dynamic view
Queue | IMP
Version | 6.1.4
Type | Enhancement
State | Rejected
Priority | 1. Low
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------
horde at headbank.co.uk (2013-11-01 16:52) wrote:
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.
More information about the bugs
mailing list