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.