Note: There are a few cases of duplicates in user autocompletion which are being worked on.

[HTML.CSS]FORM has bottom margin

VERIFIED FIXED in mozilla1.8beta2



17 years ago
12 years ago


(Reporter: karnaze (gone), Assigned: annevk)


(Blocks: 1 bug, {compat, polish, testcase})

compat, polish, testcase

Firefox Tracking Flags

(Not tracked)



(4 attachments)



17 years ago
This is an off shoot of bug 31153. The line containing the text field is too 
tall. If the <input> is replaced with plain text, the same thing happens.

<div style="border: 1px solid red">
    <input value=foo>
Created attachment 10330 [details]
Created attachment 10331 [details]
clearer testcase
Summary: block containing form is too tall → [BLOCK]bottom margin of FORM not carried out of DIV
Wait a sec... margins aren't carried out when there are borders.  The problem is
that html.css says:

436 form {
437 display: block;
438 margin: 0px 0px 1em 0px;
439 }

So, why does it have these margins?  Eric Pollman made them that way.  Must be
backwards compatibility.  This seems like something strange enough that maybe it
should be in quirks.css.
Summary: [BLOCK]bottom margin of FORM not carried out of DIV → [HTML.CSS]FORM has bottom margin

Comment 4

17 years ago
From my checkin comment (rev 3.40, 2000-Jan-13):

Bug 16253: Update form margins to be the same as Nav and IE's (this checkin has 
no effect on layout until 23388 is fixed) r=harishd

Yes, this is a quirk thing - quirk.css, unfortunately, was not around until a 
few months after this change.  :)  If this behaviour differs from the spec, 
please feel free to move it to the right place!
Giving this to Eric Pollmann.  I think page authors would be happy to get rid of 
behavior like this, so IMO it should go to quirks.css.  cc:ing Ian to see if he 
Assignee: buster → pollmann
I do think the quirky margin should be moved to quirks.css; what I'm not sure
of is what margins we should have in the html.css file. 1em top and bottom?
0 margins all round?

Does it matter?

I would say 0 margins all round; forms usually contain paragraphs or somesuch
that will have margins of their own.
Keywords: compat

Comment 7

17 years ago
From bug 16253:

Nav   4.7  1em bottom margin only
IE    5.0  1em bottom margin some cases 0 margins other cases
Opera 3.61 0.5em(?) top and bottom margins
Gecko      1em bottom margin only

I'll check in IE to see if the two margins are consistently chosen (for example, 
based on if the form is well nested or not?)
Target Milestone: --- → M18

Comment 8

17 years ago
This is *such* a low risk, one-liner fix it would be silly not to get it in for 
Keywords: nsbeta3, polish
Whiteboard: fix almost in hand
Marking nsbeta3-
Whiteboard: fix almost in hand → [nsbeta3-]fix almost in hand

Comment 10

17 years ago
Moving bug marked nsbeta3- to Future milestone.
Target Milestone: M18 → Future

Comment 11

17 years ago
*** Bug 50408 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
*** Bug 52982 has been marked as a duplicate of this bug. ***

Comment 13

17 years ago
*** Bug 59911 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
You may want to check out Bug 62245.
Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.
Keywords: testcase
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov

Comment 17

15 years ago
*** Bug 158978 has been marked as a duplicate of this bug. ***

Comment 18

15 years ago
So could we decide on something here and just do it?
Assignee: alexsavulov → dbaron
Whiteboard: [nsbeta3-]fix almost in hand → [patch][nsbeta3-]fix almost in hand
*** Bug 50408 has been marked as a duplicate of this bug. ***


13 years ago
Blocks: 56362
*** Bug 245993 has been marked as a duplicate of this bug. ***

Comment 22

13 years ago
Created attachment 174229 [details] [diff] [review]
patch #1
Assignee: dbaron → bug
Attachment #174229 - Flags: superreview?(bzbarsky)
Attachment #174229 - Flags: review?(bzbarsky)


13 years ago
Attachment #174229 - Flags: superreview?(dbaron)
Attachment #174229 - Flags: superreview?(bzbarsky)
Attachment #174229 - Flags: review?(bzbarsky)
Attachment #174229 - Flags: review+


13 years ago
OS: Windows NT → All
Hardware: PC → All
Whiteboard: [patch][nsbeta3-]fix almost in hand → [patch]
Target Milestone: Future → mozilla1.8beta2
Attachment #174229 - Flags: superreview?(dbaron) → superreview+

Comment 23

13 years ago
Checked in for 1.8b2
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 24

13 years ago
Created attachment 174856 [details]
testcase (standards mode)


13 years ago
Whiteboard: [patch]

Comment 25

13 years ago
These new css files (i.e. forms.css, html.css, quirk.css) change the appearance
of .  The forms on the left ("Type distribution name"
area), middle ("News filtering options" area), and right ("Data span" area) are
now "sunk", meaning the bottom extends outside the box border.

The previous versions of those css files showed correctly
with those forms completely inside their box.

I identified these files as the cause, not only from compiling my own OS/2
version (using dates "2005-02-17 22:12 PST" and "2005-02-17 22:14 PST") but also
testing precompiled (binaries from Win98 version 2005-02-17-06 and
2005-02-18-07 trunk, as well as precompiled Win98 Firefox release (here I just
changed those css files, restart Firefox, change css files, restart, etc).

Comment 26

13 years ago
That site is in standards mode, and the "sunk" rendering is correct given their CSS.

Comment 27

12 years ago
*** Bug 286714 has been marked as a duplicate of this bug. ***
The issue in comment 25 is fixed by bug 305975 (so there was a bug in Mozilla
that got visible by the fix for this bug).
You need to log in before you can comment on or make changes to this bug.