Shashi Narain Reporter
	Description • 25 years ago

After the page loads, look at the black table cell containing the white text 
"Welcome". This cell is huge :-)

You may want to take a look at one of the demos at the site 
(http://www.narain.com/gecko/css/football.html). Because of this bug, the entire 
layout of the page is ruined.

The code used within these table cells look something like this:

<div class="someclass"><p>Some Text</p></div>

On a side note...these pages have always rendered correctly with past builds. 
This bug only showed up a few weeks ago.

	troy
	Comment 1 • 25 years ago

Changing component

	Doron Rosenberg (IBM)
	Comment 2 • 25 years ago

are you seeing this with m15?

	Doron Rosenberg (IBM)
	Comment 3 • 25 years ago

this smells of bug 28920.  marking dup of it.


*** This bug has been marked as a duplicate of 28920 ***

	buster
	Comment 4 • 24 years ago

This is not a duplicate.  Doron, please be more careful when marking bugs
dupliate.  Without a minimized test case or similar evidence to prove it's
exactly the same problem, you shouldn't dup a bug.

	buster
	Comment 5 • 24 years ago

We need a minimized test case for this.  Any takers?
Reducing severity, critical is reserved for more serious bugs than this.

	Blake Ross
	Comment 6 • 24 years ago

i'll make it

	Doron Rosenberg (IBM)
	Comment 7 • 24 years ago

my bad. The offending code is <div class="section"><p>Welcome</p></div>

The <P></P> causes line breakes, removing em fixes the bug. Since it is in a
table, it looked to me like a dupe. Seems to however work only now if a DIV is
included.

Adding testcase

	Hixie (not reading bugmail)
	Comment 9 • 24 years ago

What is shown in the attachement is not a bug per the CSS spec. It can be fixed 
by adding the following to the stylesheet:

   div.section > p { margin: 0; }

...or just removing the <p> tags inside the table cell (on the original page).
I'm not marking this INVALID, though, since Shashi doesn't like it when I 
do that. ;-)

	Shashi Narain Reporter
	Comment 10 • 24 years ago

Ian ---

As you can see, the "Footworld World" page looks absolutely hideous with current 
Moz builds. I designed this page back in the summer of 1997...6 months after the 
release of the CSS1 specs. This page has stood the test of time by being 
viewable to IE3/4/5, NN4, and even Moz. Something happened around early-March 
that caused my pages to become grotesque.

<soapbox>
The bottom-line is that my code is valid and has been since the early days of 
CSS. I see no reason why I should change my code, which has lasted for 3 years, 
just because Moz suddenly decides to interpret it differently.
</soapbox>

Judging from the "solution" you provide, it seems that <p>'s are given margins 
larger than "0" by default and thus causing my cells to look huge. Is my 
understanding correct here??? If it is correct, then why have the margins been 
set to larger than "0"??? The default should be "0" unless I specify otherwise 
on my stylesheet (which over-rides the default).

	Hixie (not reading bugmail)
	Comment 11 • 24 years ago

<soapbox> <!-- ignore this bit please... -->
You cannot rely on user agents rendering pages in a given way. User agents are
free to use any sort of default stylesheet they like, and users are free to 
use whatever default user stylesheet they like too.
</soapbox>

The default margins on paragraphs has always been 1em -- try it. It just so
happens that a *bug* in legacy browsers has caused margins inside cells to be
collapsed at the edges. This should not ever happen, according to CSS1.

The fix to your page is simple, mind you. Just remove the <p> tags. The text is
already inside a <div>, so the paragraph tags are redundant. (That page is not
using very semantic markup anyway, so there is no loss.)

	karnaze (gone)
	Comment 13 • 24 years ago

The 2nd attachment adds a rule to quirk.css which easily fixes the problem. Are 
there other rules that need to be added? I'm replacing "WONTFIX" in the status 
field to "fix-in-hand".

	Asa Dotzler [:asa]
	Comment 14 • 24 years ago

is this fix still any good? do we want it togo in?  It's been a while since this
bug was touched.

	karnaze (gone)
	Comment 15 • 24 years ago

Marking mozilla0.8 (I need to re-test the patch).

	Mats Palmgren (inactive)
	Comment 16 • 24 years ago

The patch (which was checked in 2000-12-21) causes problems, see bug 63983.

	Mats Palmgren (inactive)
	Comment 17 • 24 years ago

There are already two rules in quirk.css that is supposed to collapse margins:

 75 /* Quirk: collapse top margin of BODY and TD and bottom margin of TD */
 76 
 77 body > :first-node, td > :first-node {
 78   margin-top: 0;
 79 }
 80 
 81 td > :last-node {
 82   margin-bottom: 0;
 83 }

The problem with the selectors above is that they only take care of immediate
children of td and body. Changing it to:

    body > :first-node, td > :first-node,
    body > :first-node > :first-node, td > :first-node > :first-node {
      margin-top: 0;
    }
    
    td > :last-node,
    td > :last-node > :last-node {
      margin-bottom: 0;
    }

fixes this bug and bug 63983, but it is not a general solution to the problem,
which I think cannot be expressed in CSS. Although you can add "> :first-node"
to any level you desire, what you need is to recurse to *any* level, which
is probably easier and more efficient to do in C++.

	karnaze (gone)
	Comment 18 • 24 years ago

Marc, I have backed out the patch because it caused bug 63785. Please look at 
the comments in that bug and here and decide what we should do. I marked this 
bug mozilla0.8 only because there was an existing patch.

	David Baron :dbaron:
	Comment 19 • 24 years ago

Mats Palmgren just pointed out what I think would be an acceptable solution -
invent a new selector, say :first-descendant and :last-descendant (although I
don't like those terms) and use that instead.

	David Baron :dbaron:
	Comment 20 • 24 years ago

That's wrong.  It would have to be :first-descendant-of(TD),
:first-descendant-of(BODY), etc.

	Marc Attinasi
	Comment 21 • 24 years ago

I'd suggest putting this off for now, unless there is a
top100 site we need to worry about.

setting severity to Normal, clearing fix-in-hand, Accepting and moving to future.

	Hixie (not reading bugmail)
	Comment 22 • 24 years ago

David: That wouldn't work.

   div { margin: 1em; }

   <td>
    <div>
     <div>
      <div>
       no margins
      </div>
     </div>
    </div>
   </td>

(Also, it would have to be :-moz-...)

	David Baron :dbaron:
	Comment 23 • 24 years ago

But this would be in the UA stylesheet so the author div rule would override it.
 Or would you want there to be no margins in that case?

	Mats Palmgren (inactive)
	Comment 24 • 24 years ago

*** Bug 72172 has been marked as a duplicate of this bug. ***

	Amarendra Hanumanula
	Comment 25 • 24 years ago

QA contact update

	Marc Attinasi
	Comment 26 • 24 years ago

--> P3 for future bugs

	Marc Attinasi
	Comment 27 • 23 years ago

*** Bug 47051 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 28 • 23 years ago

*** Bug 96966 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 29 • 23 years ago

*** Bug 98809 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 30 • 23 years ago

An alternative solution would be to make the 'margin' and 'margin-*' properties
"shorthand" properties, in a sense, that both set the margin and set
-moz-margin-top-ignore and -moz-margin-bottom-ignore to 'none'. 
'-moz-margin-top-ignore' and '-moz-margin-bottom-ignore' could then be set to
'if-edge' in ua.css and the block layout code could figure out when to do the
ignoring.

	Hixie (not reading bugmail)
	Comment 32 • 23 years ago

Well... maybe once we've solved some of our more urgent and much more serious CSS1 
and CSS2 bugs? ;-) Do we really want to fix this at all?

	Mats Palmgren (inactive)
	Comment 33 • 23 years ago

*** Bug 104000 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 34 • 22 years ago

*** Bug 29447 has been marked as a duplicate of this bug. ***

	Hixie (not reading bugmail)
	Comment 35 • 22 years ago

*** Bug 147312 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 36 • 22 years ago

*** Bug 158837 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 37 • 22 years ago

*** Bug 161029 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 38 • 22 years ago

*** Bug 162374 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 39 • 22 years ago

*** Bug 162811 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 40 • 22 years ago

*** Bug 179841 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 41 • 22 years ago

*** Bug 44264 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 42 • 22 years ago

There's a good bit of discussion of this bug in bug 44264, and a little in other
of the duplicates, such as bug 179841.  Taking this bug, since the solution is
most likely in the style system, if we come up with one, although it's not high
priority.

	Hixie (not reading bugmail)
	Comment 43 • 22 years ago

An extension of the idea in comment 30 is to change our quirk so that instead of 
the masses of CSS rules in quirk.css, we just changed the margins of <p>, etc, to 
be in a different set of units, e.g., _moz_quirky_em, which we then say acts like
an 'em' in all cases except in quirks mode at the top of a block.

	David Baron :dbaron:
	Comment 44 • 22 years ago

*** Bug 181093 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 45 • 22 years ago

*** Bug 199795 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 46 • 22 years ago

*** Bug 65893 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 47 • 22 years ago

*** Bug 198585 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 48 • 22 years ago

*** Bug 75878 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 49 • 21 years ago

Here is another case which came up in bug 209193:
<td><form><input type="hidden"></form><div>DIV</div></td>

See also bug 172902

	Mats Palmgren (inactive)
	Comment 50 • 21 years ago

*** Bug 209193 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 51 • 21 years ago

The solution proposed in comment 20 would not fix the bug for many of the cases
where margins collapsing through an element are involved.

	Hixie (not reading bugmail)
	Comment 52 • 21 years ago

*** Bug 194793 has been marked as a duplicate of this bug. ***

	Hixie (not reading bugmail)
	Comment 53 • 21 years ago

My preferred fix for this would be that described in comment 43.

	Hixie (not reading bugmail)
	Comment 54 • 21 years ago

*** Bug 219301 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 55 • 21 years ago

*** Bug 62249 has been marked as a duplicate of this bug. ***

	Boris Zbarsky [:bzbarsky]
	Comment 56 • 21 years ago

*** Bug 96966 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 57 • 21 years ago

*** Bug 228547 has been marked as a duplicate of this bug. ***

	Mats Palmgren (inactive)
	Comment 58 • 21 years ago

*** Bug 231290 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 59 • 20 years ago

*** Bug 243554 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 60 • 20 years ago

*** Bug 269327 has been marked as a duplicate of this bug. ***

	Boris Zbarsky [:bzbarsky]
	Comment 61 • 20 years ago

*** Bug 269007 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 62 • 19 years ago

*** Bug 295026 has been marked as a duplicate of this bug. ***

	David Baron :dbaron:
	Comment 63 • 17 years ago

Fixing this properly would allow us to remove the rules in quirks.css that sort of do this, which would probably yield a performance gain.

	realgrouchy
	Comment 64 • 17 years ago

This but also affects bottom-alignment in tables where one cell has a <p> tag. See attachment "testcase 4" for example.

	Sylvestre Ledru [:Sylvestre]
	Comment 68 • 6 years ago

No assignee, updating the status.

	Sylvestre Ledru [:Sylvestre]
	Comment 69 • 6 years ago

No assignee, updating the status.

	Sylvestre Ledru [:Sylvestre]
	Comment 70 • 6 years ago

No assignee, updating the status.