Open
Bug 82160
Opened 23 years ago
Updated 2 years ago
TEXTAREAs should always have a vertical scrollbar by default
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
REOPENED
Future
People
(Reporter: mpt, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
(deleted),
text/html
|
Details |
Build: 2001052115, Mac OS 9.1
To reproduce:
* Look at the right edge of the `Additional comments:' field in this bug
report.
What you should see:
* A disabled scrollbar.
What you actually see:
* Nothing.
A textarea should always have a scrollbar, whether enabled or not, for two main
reasons. Firstly, it provides a valuable visual cue that what you're looking at
is a textarea, rather than just a white rectangle. And secondly, it avoids the
problem that the width of the textarea is dependent on the number of lines of
text in the textarea. In Mozilla currently, as soon as I enter more lines than
will fit in the displayed part of the textarea, the textarea gets two or three
characters narrower and all my lovely bulleted lists of steps to reproduce are
rewrapped to smithereens.
Comment 1•23 years ago
|
||
All/All. I can't believe we haven't filed this before.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Comment 2•23 years ago
|
||
Strange. Under linux the scrollbar appears as soon as the first character is
typed. Sounds like on mpt's setup this isn't the case?
Reporter | ||
Comment 3•23 years ago
|
||
The scrollbar should be present whether or not you've typed *any* characters.
Currently on Mac OS it only appears once there is too much text to display all
at once.
Comment 4•23 years ago
|
||
mpt, should it be both a vertical, disabled and a horizontal, disabled scrollbar?
Reporter | ||
Comment 5•23 years ago
|
||
4.x has both. IE has just the vertical one. I think just the vertical one is
necessary to stop the wrapping problem.
4.77win32 only has the vertical one.
> it provides a valuable visual cue that what you're looking at
> is a textarea, rather than just a white rectangle.
Or it could be an <iframe>.
imo the rewrapping is a separate bug.
If it's possible for a text area to limit the user to X lines (where X is not
greater than the number visible in the textarea) should we still display a
scrollbar?
Summary: TEXTAREAs should always have a scrollbar → TEXTAREAs should always have a vertical scrollbar
Reporter | ||
Comment 7•23 years ago
|
||
I think IFRAMEs shouldn't have a vertical scrollbar by default, but top-level
BODYs should (that's bug 72540). Companion bugs to this one also need to be
filed for HTML listboxes and XUL listboxes.
I disagree that the rewrapping is a separate bug; if it was, then while you
didn't have a scrollbar you'd be wrapping ~20 pixels short of the edge of the
textarea, which would seem quite strange.
Updated•23 years ago
|
Summary: TEXTAREAs should always have a vertical scrollbar → [DUP]TEXTAREAs should always have a vertical scrollbar
Reporter | ||
Comment 9•23 years ago
|
||
I just checked all open bugs in the HTML Form Controls component. This bug
doesn't appear to be a dup, though bug 72127 is somewhat similar.
Summary: [DUP]TEXTAREAs should always have a vertical scrollbar → TEXTAREAs should always have a vertical scrollbar
Comment 10•23 years ago
|
||
And what about bug #72101 ? Seems like dup.
Comment 11•23 years ago
|
||
please ! don't add infunctional greyed-out scrollbars to _every_ damn textarea.
that only consumes space. when i got my first mozilla (M18) i was so happy to
see that it only displayed them when needed. very smart!
forms are the ugliest thing on the web for a designer. but mozilla has the most
beautiful form elements of all browsers. leave it like that.
at least leave the possibility open disable showing both scrollbars by default.
analog to frames that'd be (v-)scrolling='yes'/'no'/'auto'
let the designer decide how his textarea should look.
> as soon as I enter more lines than
> will fit in the displayed part of the textarea, the textarea gets two or three
> characters narrower and all my lovely bulleted lists of steps to reproduce are
> rewrapped to smithereens.
this shouldn't matter since the 'automatic' line wraps are 'virtual', they don't
get transmitted to the CGI. so the script processing your text will format it
the way you intended it to look.
Comment 12•23 years ago
|
||
> this shouldn't matter since the 'automatic' line wraps are 'virtual', they
> don't get transmitted to the CGI. so the script processing your text will
> format it the way you intended it to look.
Er, no. Bugzilla displays comments as it received them, and as you can see in
this page's source, wrap is set to 'hard', thus wysisyg, making the re-wrap of
importance.
Comment 13•23 years ago
|
||
Bug 64807 is about why our current behavior is different on Linux.
Comment 14•23 years ago
|
||
Always? ...This is close to saying that EVERY link needs to be blue and
underlined. designers need to beable to control the overflow of any element that
has "overflow". We need to give the designer the upperhand here, if anything,
take the IE5 approach... scrollbars are there by default but overflow:auto takes
them out till they are needed. Personally, I like it the way it is now.
Comment 15•23 years ago
|
||
When viewed on an active matrix laptop screen it is extremely difficult to see
the right and bottom bounds of the textarea (it looks like a bevel). If the
disabled scrollbar isn't placed there, may I suggest we darken the colors
slightly.
Reporter | ||
Comment 16•23 years ago
|
||
Resummarizing to make puddy happy. Yes, this should be overridable using CSS.
Summary: TEXTAREAs should always have a vertical scrollbar → TEXTAREAs should always have a vertical scrollbar by default
Comment 17•23 years ago
|
||
Isn't this an embedding issue, since IE has it and Gecko doesn't? Also, wouldn't
this cause some pages to layout differently? We expect Gecko to seamlessly
replace IE for Important Embedding Customers; might this not be an area of
cognitive friction for their users? Is it easy to fix?
Comment 18•23 years ago
|
||
I was planning on filing a separate bug, but it probably would have been
marked as a duplicate of this one, even though this one misses the point.
The problem is very specifically that the width of a textarea changes when the
scrollbar is added after typing some number of lines. It is very annoying when
you are writing a message for a online forum and did *not* happen with Netscape
4.7.
Another way to fix the problem would be to add the scrollbar to the left of
the textarea and leave the textarea at the original width which is specified
in the HTML for the form anyway. The scrollbar changes the width, deviating
from the textarea geometry that was requested in the HTML.
Whether or not the scrollbar is always there is an orthogonal issue to the width
changing. You can fix it by always including the scrollbar (and getting the
width correct!) or you can fix it by adding the scrollbar to the right of the
text area without changing the size of the textarea (this may require relaying
out the page, but that happens if you resize the window anyway).
Comment 19•23 years ago
|
||
Comment 20•23 years ago
|
||
> The problem is very specifically that the width of a textarea changes when the
> scrollbar is added after typing some number of lines.
This cannot be stressed enough. Go look at bug 72101. In particular, it has
a testcase where a text box and a text area, both set to the same width.
However, when you look at them, the textarea appears wider. When you finally
type enough lines to make the scrollbar appear, then you see that the scrollbar
gets displayed inside the textarea box, making the usable columns the same size
as the text box above it.
This can be fixed in one of two ways, and I have no preference between the two.
1. Have the scrollbar always appear.
2. Have the outline of the textarea box stop at the correct column, and have
the scrollbar appear to the _right_ of the textarea box outline when the
scrollbar is actually needed.
It makes no sense to define a textarea of width "40" and then make it appear
initially with "41" or "42" columns.
Comment 21•20 years ago
|
||
Updated•16 years ago
|
Assignee: rods → nobody
Status: ASSIGNED → NEW
Updated•16 years ago
|
QA Contact: vladimire → layout.form-controls
Comment 22•15 years ago
|
||
I have seen many bad user experiences with too many scrollbars on page in IE.
Many intranet application are created by developers who have higher resolutions.
When user have lower resolution they end up seeing lot of scrollbars
and it is confusing.
Now the resizer control is there at right-bottom corner of TEXTAREA
so TEXTAREA is easily distinguishable now.
Related bug 72540 is WONTFIX now, I vote this should also be WONTFIX
If web developer always want a scrollbar in TEXTAREA,
they can add that to their style sheet.
Comment 23•12 years ago
|
||
I was going through bugs and seen that one. I think like Biju and I even think that this is not a bug anymore.
UX nowadays seem to remove has much as possible scrollbars therefore I think it should be the same it Textarea.
Moreover Chrome does the same...
Consequently I think this bug should be INVALID or WONTFIX no?
Comment 24•12 years ago
|
||
I tend to agree with the last two comments. This is also the behaviour of Chrome and Opera.
I'm marking this WONTFIX.
Please, reopen if you disagree with the rationales given above.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Comment 25•12 years ago
|
||
Yeah, disagree with the rationales given above.
However, because every textarea now a resizer widget, they don't look that much as random white rectangles anymore.
However, there is still the problem of suddenly rewrapping when the typed text in the textarea gets too large.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 26•12 years ago
|
||
So which one of these seem the best solution:
1. Have the scrollbar always appear.
2. Have the outline of the textarea box stop at the correct column, and have
the scrollbar appear to the _right_ of the textarea box outline when the
scrollbar is actually needed.
I really don't see the point of having the scrollbar to always appear...
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•