82265 - [FIXr]Small CSS line-height causes form elements to display oddly

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P1)

Description

[Aaron Kaluszka]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9+) Gecko/20010522

See attached document.  Problem is especially apparent on select box.  Can be
worked-around with: 
input{line-height:115%;}
select{line-height:115%;}
textarea{line-height:115%;}
May be by design.

Comment 1

[Aaron Kaluszka]

Attachment: Testcase

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Perhaps the way to fix this is by rules in ua.css?  Although really it might be
nice if the form controls used something less general than the block & inline
layout code.

Comment 3

[Hixie (not reading bugmail)]

Why is this a bug?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Form elements shouldn't be affected by line-height in this way.  (Find the part
of CSS2 that says that they should be. :-)

Comment 5

[Hixie (not reading bugmail)]

Find the part that says they are special cased. :-)

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Find the general case that they're an example of. :-)

Comment 7

[Hixie (not reading bugmail)]

Does 'inline-block' count? :-)

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

When you can point to a specification that describes how its contents can be
rendered and can describe the rendering of form controls in terms of it.

Comment 9

[Hixie (not reading bugmail)]

Well, the form controls can be described in terms of inline-block and the XUL-
style box model, as demonstrated by, er, XUL. That's not normative though,
granted. Time for me to work some more on my UI draft...

However, just because the spec doesn't say that form controls shouldn't be
affected by line-height doesn't imply the opposite. Should 'background' affect
form controls? Many web authors certainly want it to.

Comment 10

[Aaron Kaluszka]

The issue I was focusing on wasn't as general as should the form elements even 
take that attribute.  What I was noting was that when it does take that 
attribute, the text is offset, but the form elements themselves are not.  It 
gets even weirder with the more complex form elements, select and textarea.  
The testcase shows them all.  In particular, look at how the select options act 
when you mouse over them.

Comment 11

[Hixie (not reading bugmail)]

Depending on how exactly we define the form controls, what we do now might
actually be correct. It's suboptimal though, IMHO, yes.

This will get fixed once we switch to truly CSS-based form controls (the XBL
form controls).

Comment 12

[doctor__j]

I think this is a dupe of bug 79999...

Comment 13

[Aaron Kaluszka]

Sort of.. but this seems to cover it better

Comment 14

[rods (gone)]

*** This bug has been marked as a duplicate of 79999 ***

Comment 15

[Vladimir Ermakov]

verifying duplicate

Comment 16

[Aaron Kaluszka]

The dropdown was fixed from bug 82626, but there are still other issues.  Look
at the test case again.  In addition, the fix might have broken something else..
to see what I mean, select all of the items in the Bugzilla query.  there are
now spaces between random selected lines.

Comment 17

[Aaron Kaluszka]

fix for bug 82626 was backed out; thus, the problem returns

Comment 18

[rods (gone)]

Moving to Future

Comment 19

[Aaron Kaluszka]

Hmm textarea seems to work properly now, but not the other form elements.

Comment 20

[Aaron Kaluszka]

The effects are even worse using XBLFC: weird scrollbars and stuff.

Comment 21

[Greg K.]

Reconfirmed using FizzillaCFM/2002071208. Setting Platform=All.

Comment 22

[Boris Zbarsky [:bzbarsky]]

OK.  I think the fact that there is a block inside the form control is
completely and utterly an implementation detail.  At the very least we should
put line-height:normal on all controls in forms.css; I would like to make that
!important, myself.  Fwiw, hyatt agrees with me.  So unless there's some
_really_ good reason we should not do it (like "that violates the spec" good;
not doing it is a compat nightmare that we should not be causing)...

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Agreed, of course.

Comment 24

[Boris Zbarsky [:bzbarsky]]

taking.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Attachment: more comprehensive testcase

Comment 26

[Boris Zbarsky [:bzbarsky]]

Attachment: disable line-height on all form controls

The only one of these which gives me any pause at all is textarea... For the
one, perhaps the setting should not be !important.  For all the rest, it should
definitely be !important.

Comment 27

[John Keiser (jkeiser)]

Comment on attachment 104279 [details] [diff] [review]
disable line-height on all form controls

r=jkeiser if you remove height: auto !important on optgroup ... maybe we need
to talk about disabling a bunch of stuff at once with a comment "disabling to
keep people from using this crap on their web pages"

Comment 28

[Boris Zbarsky [:bzbarsky]]

Attachment: same without height: auto !important

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 104577 [details] [diff] [review]
same without height: auto !important

sr=dbaron (and transferring r=jkeiser)

Comment 30

[Boris Zbarsky [:bzbarsky]]

fixed for 1.3a

Comment 31

[Vladimir Ermakov]

verifying build 2003-01-17-04-trunk