Closed
Bug 44264
Opened 25 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)
Core
Layout
Tracking
()
Future
People
(Reporter: dbaron, Assigned: attinasi)
References
Details
(Keywords: compat, Whiteboard: [nsbeta2-] (py8ieh:make more test cases?) WONTFIX?)
Attachments
(1 file)
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
|
||
Comment 1•25 years ago
|
||
Putting on [nsbeta2-] radar. Not critical to beta2. Adding "nsbeta3" keyword
for consideration of a fix for that milestone.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
|
Reporter | |
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M17
|
||
Comment 2•25 years ago
|
||
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?)
|
|
Reporter | |
Comment 3•25 years ago
|
||
|
|
Reporter | |
Updated•25 years ago
|
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
|
|
Reporter | |
Updated•25 years ago
|
Target Milestone: M17 → M18
|
|
Reporter | |
Comment 4•24 years ago
|
||
Giving margin collapsing bugs that I have not fixed to buster.
Assignee: dbaron → buster
Status: ASSIGNED → NEW
Target Milestone: M18 → ---
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
|
|
Reporter | |
Comment 7•24 years ago
|
||
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
|
|
Reporter | |
Comment 9•24 years ago
|
||
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.
|
||
Comment 10•24 years ago
|
||
P3 bugs are getting moved to "future" milestone. They will not be addressed for
NS6 RTM.
Target Milestone: --- → Future
|
||
Updated•24 years ago
|
QA Contact: petersen → chrisd
|
|
||
Comment 11•24 years ago
|
||
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?
|
|
||
Comment 12•24 years ago
|
||
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
|
||
Comment 13•24 years ago
|
||
*** Bug 94704 has been marked as a duplicate of this bug. ***
|
||
Comment 14•23 years ago
|
||
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: ASSIGNED → NEW
|
|
Reporter | |
Comment 15•23 years ago
|
||
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.
|
|
Reporter | |
Comment 16•23 years ago
|
||
*** Bug 86964 has been marked as a duplicate of this bug. ***
|
||
Updated•23 years ago
|
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
|
|
Reporter | |
Comment 17•22 years ago
|
||
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.
Description
•