Closed Bug 41806 Opened 20 years ago Closed 15 years ago

[HTML.CSS]FORM has bottom margin

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla1.8beta2

People

(Reporter: karnaze, Assigned: annevk)

References

Details

(Keywords: compat, polish, testcase)

Attachments

(4 files)

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">
  <form>
    <input value=foo>
  </form>
</div>
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
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 
agrees.
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
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?)
Status: NEW → ASSIGNED
Target Milestone: --- → M18
This is *such* a low risk, one-liner fix it would be silly not to get it in for 
beta3.
Keywords: nsbeta3, polish
Whiteboard: fix almost in hand
Marking nsbeta3-
Whiteboard: fix almost in hand → [nsbeta3-]fix almost in hand
Moving bug marked nsbeta3- to Future milestone.
Target Milestone: M18 → Future
*** Bug 50408 has been marked as a duplicate of this bug. ***
*** Bug 52982 has been marked as a duplicate of this bug. ***
*** Bug 59911 has been marked as a duplicate of this bug. ***
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
Status: ASSIGNED → NEW
*** Bug 158978 has been marked as a duplicate of this bug. ***
So could we decide on something here and just do it?
Taking.
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. ***
Blocks: 56362
*** Bug 245993 has been marked as a duplicate of this bug. ***
Attached patch patch #1Splinter Review
Assignee: dbaron → bug
Status: NEW → ASSIGNED
Attachment #174229 - Flags: superreview?(bzbarsky)
Attachment #174229 - Flags: review?(bzbarsky)
Attachment #174229 - Flags: superreview?(dbaron)
Attachment #174229 - Flags: superreview?(bzbarsky)
Attachment #174229 - Flags: review?(bzbarsky)
Attachment #174229 - Flags: review+
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+
Checked in for 1.8b2
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Whiteboard: [patch]
These new css files (i.e. forms.css, html.css, quirk.css) change the appearance
of http://distrowatch.com .  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 http://distrowatch.com 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 mozilla.org) 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).
That site is in standards mode, and the "sunk" rendering is correct given their CSS.
*** 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.