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.

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.

Why is this a bug?

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

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

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

Does 'inline-block' count? :-)

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.

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.

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.

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).

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

Sort of.. but this seems to cover it better

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

verifying duplicate

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.

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

Moving to Future

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

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

Reconfirmed using FizzillaCFM/2002071208. Setting Platform=All.

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)...

Agreed, of course.

taking.

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 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 on attachment 104577 [details] [diff] [review] same without height: auto !important sr=dbaron (and transferring r=jkeiser)

fixed for 1.3a

verifying build 2003-01-17-04-trunk