Closed
Bug 41806
Opened 24 years ago
Closed 19 years ago
[HTML.CSS]FORM has bottom margin
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla1.8beta2
People
(Reporter: karnaze, Assigned: annevk)
References
Details
(Keywords: compat, polish, testcase)
Attachments
(4 files)
123 bytes,
text/html
|
Details | |
157 bytes,
text/html
|
Details | |
2.15 KB,
patch
|
bzbarsky
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
200 bytes,
text/html
|
Details |
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
Comment 4•24 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 agrees.
Assignee: buster → pollmann
Comment 6•24 years ago
|
||
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•24 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?)
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Comment 8•24 years ago
|
||
This is *such* a low risk, one-liner fix it would be silly not to get it in for beta3.
Comment 9•24 years ago
|
||
Marking nsbeta3-
Whiteboard: fix almost in hand → [nsbeta3-]fix almost in hand
Comment 10•24 years ago
|
||
Moving bug marked nsbeta3- to Future milestone.
Target Milestone: M18 → Future
Comment 11•24 years ago
|
||
*** Bug 50408 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 52982 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
*** Bug 59911 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
You may want to check out Bug 62245.
Comment 15•24 years ago
|
||
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
Comment 16•23 years ago
|
||
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
Status: ASSIGNED → NEW
Comment 17•22 years ago
|
||
*** Bug 158978 has been marked as a duplicate of this bug. ***
Comment 18•21 years ago
|
||
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. ***
*** Bug 245993 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 22•19 years ago
|
||
Assignee: dbaron → bug
Status: NEW → ASSIGNED
Attachment #174229 -
Flags: superreview?(bzbarsky)
Attachment #174229 -
Flags: review?(bzbarsky)
Updated•19 years ago
|
Attachment #174229 -
Flags: superreview?(dbaron)
Attachment #174229 -
Flags: superreview?(bzbarsky)
Attachment #174229 -
Flags: review?(bzbarsky)
Attachment #174229 -
Flags: review+
Assignee | ||
Updated•19 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•19 years ago
|
||
Checked in for 1.8b2
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 24•19 years ago
|
||
Assignee | ||
Updated•19 years ago
|
Comment 25•19 years ago
|
||
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).
Comment 26•19 years ago
|
||
That site is in standards mode, and the "sunk" rendering is correct given their CSS.
Comment 27•19 years ago
|
||
*** Bug 286714 has been marked as a duplicate of this bug. ***
Comment 28•19 years ago
|
||
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.
Description
•