The default bug view has changed. See this FAQ.

CSS in form elements is a crapshoot

NEW
Unassigned

Status

()

Core
Layout: Form Controls
12 years ago
7 years ago

People

(Reporter: Garrett Smith, Unassigned)

Tracking

({testcase})

Other Branch
PowerPC
Mac OS X
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050726
Firefox/1.0+

CSS in form elements is a crapshoot.

Different results in different browsers. 

Button elements:
 * Different amounts of extra padding for in Mozilla, Opera, and IE.
 * nested floats don't work right, e.g. <button
style="float:left;position:relative"><div style="position: absolute;left:
0"></div></button>


Mozilla does not change the display of form elements to block (or inline, or
table-cell, et c). Instead, it exhibits an undefined, unocumented behavior.


For example
<button style="display: block; border:1px solid
red;padding:0;margin:0"><div>content</div></button>

Expected Result: 

Changing the display of a form element should result in an element that is
visually rendered according to that display. No checkbox indicators for
checkboxes and no extra padding for buttons or input type="button". Unless the
author uses display: auto.

If display: block is specified, the UA should display a block-level element. 

The only exception to this could be the input type="file", and only for security
reasons.
(Reporter)

Comment 1

12 years ago
Created attachment 192602 [details]
compare div and input elements using display: block

The div elements look fine.

The input type="button" elements have too much padding.

The checkbox is not displayed as a block element, but instead as a checkbox.

The button element has too much padding.
I argued against making form elements stylable without a coherent plan.

(IMO, the form controls should have their own 'display' values and should be
unstylable unless 'display' is changed.  But it's way too late for anything that
simple.)

At this point it would be more useful to have one bug per issue.  A bug that
complains about large numbers of problems without describing any of them clearly
is less likely to get fixed.  (Unless, of course, somebody starts by designing
how it should work...)
Component: General → Layout: Form Controls
Product: Firefox → Core
QA Contact: general → layout.form-controls
Version: 1.0 Branch → Other Branch
(In reply to comment #2)
> I argued against making form elements stylable without a coherent plan.

Not in advance, though, but not too long after it was done.
(Reporter)

Comment 4

12 years ago
Property:      -moz-form-css:
values:        auto|no-override|override|inherit
initial value: inherit
Applies to:    Form control elements

Description:

If the value is auto, the form elements are rendered according to the
user agent. The user agent may apply some styling to the form elements

If the value is set to no-override, then the user-agent must not allow
styling of any elements

If the value is set to override and the element's display is set to any value
other than "auto", the element will be rendered according to the css.

The default value is inherit. This allows authors to set the property
on individual forms, a section of a form containing special
author-designed inputs, or on the entire form.

For example:
<form style="-moz-form-css: override">
<input type="checkbox" style="display: block; height: 12px; width: 12px;
background: orange;" />
</form>

Would result in an orange block with no checkbox indicator. The checkbox could
receive focus and be checked. To create a visual "checked" effect, the developer
would have to use the :checked pseudo-class, perhaps to use a custom check
indicator.

checkbox:checked {
    background: url(checkbox_checked.png);
}
You need to log in before you can comment on or make changes to this bug.