148317 - CSS formating is inconsistent for different form attributes.

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Rodd Clarkson]

The url above shows the sample html page with all the various form elements.

I will attach a copy of the html after posting this initial bug report.  Forgive
the bright colors.  They are used simply to help see what effect the different
css elements are having.

The problem I am seeing is that different form elements display CSS formating
inconsistently, making it difficult to create forms that are consistent in look,
but not using the default look.

In the example I have given, the following form elements seem to do the Right
Thing(tm).

<input type="button" ...>
<input type="hidden" ...>
<input type="reset" ...>
<input type="submit" ...>
<input type="text" ...>
<textarea ...></textarea>

The following form elements don't seem to be doing the right thing (tm) and I'll
explain what I think they should be doing.

<input type="checkbox" ...>

The border is too thick.  It seems to be adding something extra to the border,
or perhaps isn't not actually responding to the border-width css element.

The padding css element is shrinking the content area of the field.  Unlike the
fields do the right thing (tm) which enlarge the size of the field to allow the
elements inside to be seen, the checkbox doesn't grow, so the 'tick' inside
becomes less visible.  I would expect the checkbox to grow to allow the tick to
remain as visible as the default view.

<input type="file" ...>

Again, the border of the field seems to be ignoring the border-width element.

Also, the button should have the same formatting as the reset, submit and button
input elements

<input type="radio" ...>

The borders again, see above.

This element also seems to totally ignore the padding css element, which while
better still seems to be wrong.

<select ...></select>

Borders again.


The fact that these elements don't correctly handle to css formating makes it
difficult to create interesting looking forms.  The forms still work as
expected, but the inconsistent look is disappointing.

Comment 1

[Rodd Clarkson]

Attachment: sample form showing all form elements and the effects of css on each

Comment 2

[Rodd Clarkson]

Attachment: same form with bright colors (oops)

Comment 3

[Adam Hauner]

<input type="file" ...> - it's bug 52500.
BTW do you know, that CSS1 and CSS2 doesn't saying anything about form controls? =)

Comment 4

[Rodd Clarkson]

The <input type="file" ...> is only one of the offending elements.

Also, while CSS1 and CSS2 may not say anything about form controls, it's still
important that if form controls are to react to css, that they react consistently.

Comment 5

[Stephen P. Morse]

reassigning

Comment 6

[Boris Zbarsky [:bzbarsky]]

> <input type="checkbox" ...>
> The border is too thick.  It seems to be adding something extra to the border,
> or perhaps isn't not actually responding to the border-width css element.

It's not responding.  See bug 106317 and bug 134927 (especially bug 134927, 
comment 15; the argument for radio and checkbox is identical).

> The padding css element is shrinking the content area of the field

That could perhaps be considered a bug, but see below.

> it's still important that if form controls are to react to css

No, it's not.  See bug 106317, comment 23 for the take of a CSS Working Group 
member on the matter....

It may make sense to morph this bug into one about the padding issue on 
radio/checkbox.  It would make more sense to file a separate clear bug, or two 
separate bugs, on those issues.

Comment 7

[Rodd Clarkson]

I can see what you are saying here, but my compaint isn't about what CSS says,
what others think CSS says, or whether we should use native widgets.

It's about consistency.  It about being able to apply css styling and having is
consistently affect all form elements.  At the moment, about the only things you
can change in form elements and remain consistent are text and the background
(and even these might be a little iffy.)

At the moment we've got a hodge podge of elements that seem to adhere to css
styling at random.  My comments on what I thought were wrong are simply a
starting point on which to launch discussion.  At the end of the day I don't
mind that much whether my comments are taken as gospel, or whether other action
is taken, but I would like to see a set of form elements that respond
consistently to CSS styling.

A great example is the <input type="file" ...> element which is essentially a
<input type="text" ...> followed by an <input type="button" ...> and yet each of
it's parts look nothing like their counterparts.  The buttons and checkboxs IMHO
should respond in a similar way, but if it's too much hassle, then just get them
so that they respond well.  ie the checkboxes tick doesn't disappear because the
padding is too big.  But at the end of the day, there's no reason why the
<select ...> and <input type="file" ...> shouldn't respond exactly the same way
that the other <input ....> elements react.

This bug is about CONSISTENCY.

Comment 8

[rods (gone)]

This is low priority for RTM, and sometime after that will will be using
XBL-based form controls, so I am setting milestone appropriately

Comment 9

[Josh Heidenreich]

I found that the textboxes and submit button on www.freewebs.com where you login
isn't shown correctly. It should have them some shade of blue. They have a class
of "alphaBox" which in hte stylesheet is:

.alphaBox{height:18px; font-size:11px; font-family:verdana; FILTER:
progid:DXImageTransform.Microsoft.Alpha( style=0,opacity=50); border:1px solid
#999999; background-color:#EFEFEF; color:#000000;}

Comment 10

[Boris Zbarsky [:bzbarsky]]

We should just decide something here.  The only way to have "consistency" here
is to disallow styling of all form control borders, which would likely cause
even more problems...  I recommend WONTFIX, myself.

Comment 11

[Rodd Clarkson]

As a web designer (and the poster of this bug) I'd love to see these issues
resolved and I'd much prefer to see the elements ion question displaying the
same sort of response to CSS as the those elements that respond appropriately.

I understand that the CSS1 and CSS2 specifications don't comment on how form
elements should be affected but I don't think it's unreasonable to expect that
they all respond in a similar manner.

I can't see why the <input type="file" ...> element isn't trivial to address. 
It's basically a text element and a button element, both of which already
respond to CSS formating in an expected way.

The other elements might involve a little more work, but the current solution,
where forms elements don't respond in similar ways to CSS makes either web pages
 or mozilla look half finished, depending on how much you know about the problem.

Comment 12

[John C. Stierheim]

Still present in the current build 1.7a  of Moz and Firefox.