Closed Bug 1583 Opened 26 years ago Closed 26 years ago

{inc} missing margin-top on DIV

Categories

(Core :: Layout, defect, P4)

Product:
Core
Component:
Layout
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: buster)

References

(
URL
)

Details

(Whiteboard: Regressed) 

The margin-top on the DIV ID="body" is gone.  (I think the small gap is
explained by body padding).  The margin-top should be *much* bigger.  I have
NG_REQUEST_VER=5.0 (this is browser-sniffed, so it's needed).
The problem is that the topmost margin of the DIV is being propogated outward so
that it can be collapsed with its parents top margin. This is correct, however,
in the name of compatability the top level container discards carried-out
margins. Otherwise trivial documetns like:

<BODY>
<P>This is a paragraph
</BODY>

look wrong because of extra vertical whitespace at the top. Not a big deal on
the page, but in a table cell its death.

Suggestions? One answer could be this (which I had implemented at one point): If
the margins are "auto" then I can zap them as I'm doing now. If they aren't auto
then use them by golly.
The best way to do it, if I understand the problem correctly, is to
implement :first-child and child and universal selectors (CSS2) and then put in
ua.css:

BODY > *:first-child {margin-top: 0;}

which should have enough specificity to top anything else in ua.css...(I think)

I didn't quite get your comment about the table cell, though...
I think this is related to the problem on my homepage,
http://www.fas.harvard.edu/~dbaron/ , where the margin-top on the first H2 in
the floating DIV.left is ignored.
See http://www.endoframe.com/css/tests/box_vert.html (reported in bug 1910) for
another example of the problems this causes.  I think you really have to give
up on this solution of destroying the top margins -- they are useful, and there
is nothing in the spec that says you should ignore them.

The auto solution is also very bad (see bug 2018).

I'm not sure what to do about this, but I think just doing it per spec is
probably OK, and people will have to learn that they can't put a P in some TD
elements and not others and expect them to line up.

The solution

TD > *:first-child { margin-top: 0; }

won't work because :first-child skips over anonymous boxes.

I think this is a tough corner but the least of the evils is to follow the spec.
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
See also bugs #3542 and #2018.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Fixed a while ago by my block box model fixup work
URL: http://www.webstandards.org/ie/ → http://www.bath.ac.uk/%7Epy8ieh/a/int...
Status: RESOLVED → REOPENED
OS: other → Windows 98
Resolution: FIXED → ---
This has regressed. See the following test case:
http://www.bath.ac.uk/%7Epy8ieh/a/internet/projects/mozilla/firsttopmargin.html
The first line, which overlaps the cats right at the top of the viewport,
should be *under* the cats. However, the margin-top value is being ignored.

(I have changed the uri as the problem is *much* more visible on this page.)
Whiteboard: Regressed
Ah. I've just discovered that this fixes itself on a reflow.

Therefore the problem is that _on the initial reflow_, the margin-top of the
first element is not applied. The *exact same problem* occurs with bugs 3543
and 3663, but for margin-bottom on the last element.
Severity: normal → minor
Priority: P2 → P4
Summary: missing margin-top on DIV → missing margin-top on DIV {incremental}
Status: REOPENED → ASSIGNED
Summary: missing margin-top on DIV {incremental} → {inc} missing margin-top on DIV
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Fixed.
Status: RESOLVED → VERIFIED
Fixed in April 5th Build.
You need to log in before you can comment on or make changes to this bug.