Closed Bug 44264 Opened 24 years ago Closed 22 years ago

[MARGIN-C][quirks] need to nuke top margins on first normal-flow kids of BODY and TD

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 33784
Milestone:
Future

People

(Reporter: dbaron, Assigned: attinasi)

References

Details

(Keywords: compat, Whiteboard: [nsbeta2-] (py8ieh:make more test cases?) WONTFIX?)

Attachments

(1 file)

the changes I have in my tree so far (I need to do other stuff in this file and I don't want to lose them)
6.68 KB, patch
Details | Diff | Splinter Review 
DESCRIPTION:  We need to nuke the top margins on normal-flow kids of BODY and 
TD, in quirks mode.  Currently we only do this if the first normal-flow child is 
also the first child, through a CSS rule.  We need to remove the CSS and use 
C++, but I don't think it's hard (add a frame state bit, add a few lines of code 
to set it and read it and nuke the APPLY_TOP_MARGIN bit in the block reflow 
state).

This bug just became somewhat more visible since I removed (to fix bug 43882) a 
quirk where it wouldn't happen *if* the margin were on a P element.  If bug 
43882 hadn't been dogfood, I wouldn't have checked in before fixing this one, 
but I still would like to get this in for beta2.  It hit about 5 or so of the 
block regression tests (5859-a, 7892, 13553, 16173, 16580 -- some of which were 
copied from major sites), so I think it's reasonably important to fix.  
Nominating nsbeta2.

STEPS TO REPRODUCE:
 * load 
http://lxr.mozilla.org/seamonkey/source/layout/html/tests/block/bugs/5859-a.html

ACTUAL RESULTS:
 * top of image is lower than top of table to its left

EXPECTED RESULTS:
 * top of image at same height as table

BUGGY ON:
 * build of 2000-06-30 (assuming I don't fix this by tomorrow :-)

WORKS CORRECTLY ON:
 * older builds, but only for P elements and no others
Putting on [nsbeta2-] radar. Not critical to beta2.  Adding "nsbeta3" keyword 
for consideration of a fix for that milestone.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
Status: NEW → ASSIGNED
Target Milestone: --- → M17
Regression test 5859-a is actually caused by bug 44419.

Investigation would seem to suggest that IE5 actually doesn't do this quirk
on the top of the BODY element. It _does_ do it on the bottom of the BODY
element; all margins seem to be collapsed there, as can be seen by this simple 
test case:

  <html> <body> <h1> hello world </h1> </body> </html>

Load that in IE5, and shrink the window until until the vertical scroll bar
gets enabled. You will see that just as it enabled, the window looks like this:

   +-----------------------------------------+--+
   |                                         |/\|   <-- 1em margin
   | hello world                             |\/|
   +-----------------------------------------+--+   <-- no bottom margin

The 44264-3 test case does show that IE5 collapses margins at the top of cells,
though. This probably all warrants closer scrutiny.
Whiteboard: [nsbeta2-] → [nsbeta2-] (py8ieh:make more test cases?)
Summary: [quirk]need to nuke top margins on first normal-flow kids of BODY and TD → [MARGIN-C][quirk]need to nuke top margins on first normal-flow kids of BODY and TD
Target Milestone: M17 → M18
Giving margin collapsing bugs that I have not fixed to buster.
Assignee: dbaron → buster
Status: ASSIGNED → NEW
Target Milestone: M18 → ---
*** Bug 49745 has been marked as a duplicate of this bug. ***
needs more investigation before I can determine if this should be beta3+ or not.
 I have a couple other bugs that need immediate attention, so please leave this
one untriaged until I do a bit more examination.  dbaron did post some
work-in-progress that might be useful.
Status: NEW → ASSIGNED
I've thought about this a little more.  I think our current behavior (simple
quirk.css hack) is OK for the vast majority of cases.  It may be that one of the
IE variants handles it the same way we do now... I'd have to check.

I also can't think of a way to fix the rest of the cases that wouldn't break CSS
margins in some significant ways.  I'd still like to keep CSS working as well as
possible in quirks mode.

In other words, I think at this point this is one of the backward-compatibility
cases I'd rather leave as it is at this point, since fixing it could be risky.
Suggest nsbeta3- based on dbaron's comments.

David, to be clear, are you saying that the workaround already exists in
quirks.css, or it will be part of Ian's .css cleanup work?  which rule, exactly?
 thanks
The rules are (something like)

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

These handle the case where the first-node is also the first normal-flow child. 
The "problem" is only when the first/last child is out-of-flow and the
first/last in-flow child has a top/bottom margin.
P3 bugs are getting moved to "future" milestone.  They will not be addressed for
NS6 RTM.
Target Milestone: --- → Future
QA Contact: petersen → chrisd
This bug also occurs with nested content, e.g.:

   <td>
    <div>
     <p>
      foo
     </p>
    </div>
   </td>

...will have 1em top and bottom margins in Moz, but not in legacy browsers. Is
that filed in some other bug?

I would suggest WONTFIXing this bug unless we get a lot of complaints from 
people once N6 is in the marketplace.
Severity: major → minor
Whiteboard: [nsbeta2-] (py8ieh:make more test cases?) → [nsbeta2-] (py8ieh:make more test cases?) WONTFIX?
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
*** Bug 94704 has been marked as a duplicate of this bug. ***
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: ASSIGNED → NEW
I'm not sure why I never noted it here, but the better way to fix this would be
to use a margin value such as '-moz-default' that had 1em/0 behavior depending
on whether the margin was at the start/end of a block with NS_BLOCK_MARGIN_ROOT
or not, or something like that.  I think I made a comment roughly saying that on
another bug somewhere.
Keywords: nsbeta2, nsbeta3
*** Bug 86964 has been marked as a duplicate of this bug. ***
Summary: [MARGIN-C][quirk]need to nuke top margins on first normal-flow kids of BODY and TD → [MARGIN-C][quirks] need to nuke top margins on first normal-flow kids of BODY and TD
I can't tell what the difference is between this and 

*** This bug has been marked as a duplicate of 33784 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: