css line-height ignored in textarea

RESOLVED FIXED in mozilla1.8alpha1

Status

RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: jc, Assigned: bzbarsky)

Tracking

Trunk
mozilla1.8alpha1
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

the line-height command seems to be totally ignored in text-area rendering

Reproducible: Always
Steps to Reproduce:
1. Open the page www.thp.org/lineheight.htm in IE or Mozilla
2.
3.

Actual Results:  
IE does it right, Mozilla does it wrong.

Expected Results:  
Mozilla should do it right.
(Assignee)

Comment 1

15 years ago
Mozilla explicitly sets the line-height "textarea" in the UA stylesheet.  See
bug 82265.

I suppose we could stop doing it for textarea in particular..... (I'm not sure
what I think of that from a general "what exactly is a form control" perspective).

Comment 2

15 years ago
Page authors have enough ways to make textareas hard to use without adding
line-height as another.
(Assignee)

Comment 3

15 years ago
Well, the issue is that we're letting the page set the font family and size but
not line-height -- that can actually decrease readability on a well-authored page.

John, how does IE handle "line-height: 0" on a textarea?

Comment 4

15 years ago
It treats it the same as 'line-height:0' on the BODY element. Showing a very
thin line of text, like Mozilla does. Only IE supports it for TEXTAREA as well.
(Assignee)

Comment 5

15 years ago
Well, the reason bug 82265 happened was that IE does not support line-height on
some controls.

So I'd sorta like to know what IE's exact behavior is... in both backcompat and
css1compat mode, by the way.

Comment 6

15 years ago
Created attachment 148047 [details]
screen shot

It shows the same behavior if I put a nice strict doctype at the top.
(Assignee)

Comment 7

15 years ago
And the same without the explicit rule for textarea?

Comment 8

15 years ago
You found the strange IE behavior. It doesn't inherit by default. (That is the
same for standard and quirks mode.)
(Assignee)

Comment 9

15 years ago
Ah, ok.  So just a matter of removing the !important on textarea in forms.css
then....

I think I'd be fine with that.  David?  Ian?

Comment 10

15 years ago
(In reply to comment #3)

> Well, the issue is that we're letting the page set the font family and size but
> not line-height -- that can actually decrease readability on a well-authored page.

I'm having a hard time imagining how refusing to apply anything except
line-height: normal to a textarea could make the textarea less readable, unless
of course the author was already styling the textarea with mousetype, and trying
to undo some damage with a larger line-height. Naturally in such a case I would
need to zoom anyway, and thus would not appreciate a larger line-height reducing
the amount of text that should otherwise fit in the available space.
It's fine with me, except you should remove the whole line.  The 'font'
shorthand sets 'line-height'.
(Assignee)

Updated

15 years ago
Attachment #148049 - Flags: superreview?(dbaron)
Attachment #148049 - Flags: review?(dbaron)
Attachment #148049 - Flags: superreview?(dbaron)
Attachment #148049 - Flags: superreview+
Attachment #148049 - Flags: review?(dbaron)
Attachment #148049 - Flags: review+
(Assignee)

Updated

15 years ago
Assignee: general → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 13

15 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha
Product: Browser → Seamonkey
*** Bug 304990 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.