Closed
Bug 165759
Opened 23 years ago
Closed 23 years ago
Problems with div layout (unordered list and margin-top).
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: george_budd, Assigned: attinasi)
References
()
Details
Attachments
(3 files)
Version 1.1b
The following page has problems with rendering the bullet quotes, they appear in
the green div, also the blank space above the div class=mtf_menu shouldn't be
there, it should be within the green box (within the div class=mtf_menu).
html and css follow:
index.html
================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>MTF Internal Home Page</TITLE>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<LINK rel=stylesheet type="text/css"
href="http://indevel/global/mtf_default.css">
</HEAD>
<BODY>
<div class=mtf_pagehead>
<table width="100%" border=0 summary="Main Page Header"><tr><td><a
href="/index.html"><IMG src="http://indevel/global/fullmtflogo.gif" alt="MTF
Logo" border=0></a></td>
<td align="right" valign="bottom">
<form action="/cgi-bin/search"><a href="http://www.mtf.org">External Home</a>
Search: <input type=text name=words size=20 maxlength=80>
<input type=submit value="Go"></form>
</td></tr></table>
</div>
<!-- MTFHEADEND -->
<div class="mtf_menu"><div class=mtf_linkhead>Links</div>
<ul>
<li><a href=/hr/index.html>Human Resources</a>
<li><a href=/eventc/index.html>Events Committee</a>
<li><a href="/dsd/index.html">Donor Services</a>
<li><a href="/tech_ops/index.html">Technical Operations</a>
<li><a href=/it/index.html>Information Technologies</a>
<li><a href="/mtf/site.jsp">Sites</a>
<li>Organizations
<ul><li>IIAM
<li>T<sup>3</sup>
<li>UCSF
</ul>
<li><a href=/reference/index.html>Reference</a>
<li><a href=/newbie/index.html>New Employee Info</a>
</ul>
</ul>
</div>
<h2>Reports</h2>
<ul>
<li>Test
<li>test2
<li>test3
</ul>
</BODY>h1, h2, h3, h4, h5, h6 {font-family: Lucida, Helvetica, Univer,
sans-serif; margin-bottom:0; margin-top: 1em}
body {font-family: garamond, palatino, times, serif; }
em {font-weight:bold}
ul {margin-top: 0; }
tr {page-break-inside:avoid;}
table { page-break-inside:avoid; }
a.ext:before {content: url(/global/ext.gif); }
div.mtf_pagehead { background-color:#339933; }
*.mtf_menu { float: left; background-color:#ccff99; width:20%}
*.mtf_pageheadpic { float: right;}
div.mtf_news h2 { margin-bottom:.25em; }
div.mtf_news h3 { margin-top: 0; margin-bottom:0; margin-left: .75em; }
*.mtf_nomarg {margin-top: 0; margin-botton:0; }
td.calhead { text-align:center; background-color:#339933;}
table.compressed h3 {margin-top:0; }
table.compressed td {font-size:90%;}
table.compressed2 td {font-size:75%;}
span.mtf_news_dashboard { font-weight:bold; font-size:150%;
font-family: lucida, helvetica, univer,
sans-serif; }
span.search_highlight { background-color:yellow; }
div.mtf_menu h3 { background-color:#ffff99; margin-top:.75em; margin-bottom:0}
div.mtf_menu ul {margin-top:0; margin-left:20}
*.mtfheadmenu { background-color:#ccff99; font-weight:bold
font-family: lucida, helvetica, univer, sans-serif;
}
*.mtf_linkhead {text-align:center; font-size:150%; font-weight: bold;
margin-top:.75em;
font-family: lucida, helvetica, univer, sans-serif;
}
.mtf_foot {clear:both}
</HTML>
mtf_default.css
=========================================
Hi there.
I spotted this bug or rather a similar occurrence a few days back and have been
analysing it since. I have come up with test case and a more precise
description. As this is my first post to Bugzilla I can't alter the status of
the bug, so ...
Bug confirmed in:
Mozilla 1.0 Build ID 2002053012
Mozilla 1.1 Build ID 2002082611
Platform:
PC
Operating System:
Windows 2000 Pro SP2
Status:
Uncomfirmed -> New (Haven't found a previous report)
Component:
Layout -> Style System
Severity:
Normal -> Major
Arguable. The bug has a big impact on webdesign. If I'm right the bug seems
trivial and should be simple to locate but I don't know the state of the code
behind the rendering.
Keywords:
testcase, layout, style system, block, align, margin, DIV, CSS, HTML
Summary/Problem:
================
When DIV is not surrounded by a border the margins of the inner elements seep
out and beyond the containing box of the DIV.
Expected "formula":
(mD)(bD)(pD){D.contentarea=[(mP)(bP)(pP)P(pP)(bP)(mP)]}(pD)(bD)(mD)
Where:
D=DIV-tag
P=P-tag
m=margin
b=border
p=padding
.contentarea=content area that the tag is surrounding.
Assuming margin of P is 1em and all other values 0:
Desired rendering:
D.contentarea=[(mP=1em)P(mP=1em)]
Actual rendering:
(mP=1em){D.contentarea=[P]}(mP=1em)
Test Case Description:
======================
I have come up with six code snippets to illustrate and help hunt down the bug.
I have used the P-tag to illustrate/provoke the problem but it can be exchanged
for any other tag with margins set to more than 0 for instance the H-tags. Each
code snippet consists of three consecutive DIV-tags. Background colors are kept
strict in the code snippets so they always correspond to the same HTML code. The
background of the first and the last DIV-tag is colored blue and they contain
only simple text. They are used as upper and lower boundary of the middle
DIV-tag. The middle DIV-tag is where the "fun" is happening.
In the first code snippet, the middle DIV-tag with background colored green only
contains simple text and aligns seamless to the other two DIV-tags.
<div style="background-color: #9999ff">DIV to align up to</div>
<div style="background-color: #00ff00">No P-tag around text in DIV (green).
Aligns seamless with DIV-elements before and after.</div>
<div style="background-color: #9999ff">DIV to align down to</div>
In the second code snippet, the middle DIV-tag contains a P-tag (background
colored yellow) with simple text. Here gabs appear between the DIV-tags. The
gabs correspond to the margins of the P-tag. This area should be green as this
is in the content area of the containing DIV-tag. Only the background of the
text within the P-tag is colored (yellow).
<div style="background-color: #9999ff">DIV to align up to</div>
<div style="background-color: #00ff00"><p style="background-color:
#ffff00">P-tag (yellow) around text in DIV (green)</p></div>
<div style="background-color: #9999ff">DIV to align down to</div>
In the third code snippet I added a 1-pixel black border to the middle DIV-tag
which provokes the correct rendering of the margins of the P to be within the
DIV. The content of the P has a yellow background as before and the background
color of the DIV can now be seen through the margins of P.
<div style="background-color: #9999ff">DIV to align up to</div>
<div style="background-color: #00ff00; border: 1px solid #000000"><p
style="background-color: #ffff00">P-tag (yellow) around text in DIV (green)
which have (black) border</p></div>
<div style="background-color: #9999ff">DIV to align down to</div>
The only difference in rendering code snippet two and three should be the
addition of the border in three.
The fourth code snippet is a copy of the second where I have added simple text
just before the starting P-tag and just after the ending P-tag. This forces the
margin of P to be relative to the simple text, and as the simple text do not
have margins the middle DIV is rendered correctly and aligned to the blue DIV-tags.
<div style="background-color: #9999ff">DIV to align up to</div>
<div style="background-color: #00ff00">Before P <p style="background-color:
#ffff00">P-tag (yellow) around text in DIV (green)</p>After P</div>
<div style="background-color: #9999ff">DIV to align down to</div>
The last two code snippets are variations of the second and third. Here the
middle DIV-tag is surrounded by an other DIV-tag with cyan background and a
padding-left of nine pixels. This should render as a cyan pillar nine pixels
wide along the left border of the middle DIV-tag. This extra DIV-tag
encapsulates the middle DIV-tag and shows that the margins of the P-tag is not
kept inside the middle DIV-tag but is put on the outside.
<div style="background-color: #9999ff">DIV to align up to</div>
<div style="background-color: #00ffff; padding-left: 9px"><div
style="background-color: #00ff00"><p style="background-color: #ffff00">P-tag
(yellow) around text in DIV (green)</p></div></div>
<div style="background-color: #9999ff">DIV to align down to</div>
<hr>
<div style="background-color: #9999ff">DIV to align up to</div>
<div style="background-color: #00ffff; padding-left: 9px"><div
style="background-color: #00ff00; border: 1px solid #000000"><p
style="background-color: #ffff00">P-tag (yellow) around text in DIV (green)
which have (black) border</p></div></div>
<div style="background-color: #9999ff">DIV to align down to</div>
I'll attach the HTML-file with testcase code snippets after posting this. Most
of the description above is present in the file. If this is wrong I can quickly
make a revision of it without the descriptions.
|
||
Comment 2•23 years ago
|
||
The margin-top seems to be ok. I think that's how it's supposed to look.
The bullets moving over into the <div> seem to be caused by the float:left
This is the testcase described in comment #1. It's a HTML-file that contains
six code snippets and description of the problem, possible cause and ofcause
the snippets.
|
|
||
Comment 4•23 years ago
|
||
the list / div / float problem is bug 57882.
I'm not sure about the margin-top part.
In essence the same testcase as submittet in comment #3 but without the
desciptions. Now you devellopers have a choice ;-).
|
||
Comment 6•23 years ago
|
||
Tempted to mark as INVALID, see CSS2 spec:
http://www.w3.org/TR/REC-CSS2/box.html#collapsing-margins
According to that page, as I understand it, the nested DIV/P combination
*should* have their margin-top/bottom "merged" so that the content areas (inner
position) are aligned, *not* the outer border. The specstates that this only
occurs if there is no padding or border, which is why it then works as you
expect when you add the 1px solid black border, and that this only (in CSS2,
anyway) affects top and bottom margins.
|
||
Comment 7•23 years ago
|
||
The margin stuff is CSS2 margin collapsing, as James points out, and is done
exactly correctly (nice testcases, by the way!).
The bullets are indeed bug 57882
*** This bug has been marked as a duplicate of 57882 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I agree that the original post (list / div / float) is bug 57882 as Andrew and
Boris says.
But regarding the CSS2 margin collapsing I don't agree that it's implemented
correct. Here is why.
James and Boris:
The CSS2 spec (http://www.w3.org/TR/REC-CSS2/box.html#collapsing-margins) says:
"In this specification, the expression collapsing margins means that adjoining
margins (no padding or border areas separate them) of two or more boxes (which
may be next to one another or nested) combine to form a single margin."
Reading The visual formatting model spec:
http://www.w3.org/TR/REC-CSS2/visuren.html#block-formatting
"In a block formatting context, boxes are laid out one after the other,
vertically, beginning at the top of a containing block. The vertical distance
between two sibling boxes is determined by the 'margin' properties. Vertical
margins between adjacent block boxes in a block formatting context collapse."
Using the notation from comment #1 this means:
In case of
<div>...</div>
<div>...</div>
(mD)(bD)(pD){D.contentarea=[...]}(pD)(bD)(mD)(mD)(bD)(pD){D.contentarea=[...]}(pD)(bD)(mD)
collaps ---------------------------------^^^^^^^^
The DIV-tags are siblings and thus have ajoining margins. The P-tag in my
testcase is a child of a DIV-tag and thus have no ajoining margins with the
other DIV-tags or for that matter the containing DIV-tag (the parent). You have
to pass a padding and a border to find the margin of the parent DIV-tag.
(mD)(bD)(pD){D.contentarea=[(mP)(bP)(pP)P(pP)(bP)(mP)]}(pD)(bD)(mD)
Here--^^^^^^^^--and there--------------------------------^^^^^^^^
It dosn´t matter that the values of the padding and border on the DIV is 0 in
the testcase. You still have to pass them to get two the margin of the DIV.
The current behavior is in my eyes wrong and Mozilla is not alone with that
implementation. In the current implementation I have to add something like a
1-pixel transparent image just within the DIV-tag to have any browser render the
DIV-tags correctly (keeping the children within the car).
The basics of my interpretaion of the specs might just explain several of the
layout / style sysytem bugs still open including bug 57882. Just follow my line
of thought and read on in the specs mentioned above about floats etc.
I propose my CSS2 margin either is opened as a new bug or if the topic has been
up before the corresponding bug is reopened and my comments and attachment added.
|
|
||
Comment 9•23 years ago
|
||
> "(which may be next to one another or nested)"
Did you miss that part? If the padding and border are both 0, then you do not
need to pass them and the margins are in fact adjoining... this is why the
behaviour changes when a 1px border is present.
CSS2.1 takes this a step further, even:
http://www.w3.org/TR/CSS21/box.html#collapsing-margins says:
"Note. Adjoining boxes may be generated by elements that are not related as
siblings or ancestors."
in the first bullet point in the list of when margins may collapse.
This has all been discussed to death before, yes... and our rendering is
correct (it's not a coincidence that it agrees with Opera's and MacIE's).
|
||
Comment 10•23 years ago
|
||
>> "(which may be next to one another or nested)"
>
>Did you miss that part?
Hmmm ... must have ... wishful thinking perhaps!?
Still don't find it logical though. When using a container like DIV I'd expect
it to encapsulate it's contents and not let it seep out and interact with the
surroundings. I am having alignment problems (similar to the testcases) caused
by the current interpretation and they are particularly visible when applying
background colors and/or images. For now I'll have to use the image hack I
descripe in comment #8 to uptain the desired behavior.
>This has all been discussed to death before, yes... and our rendering is
>correct (it's not a coincidence that it agrees with Opera's and MacIE's).
I know it's not a coincidence that the current implementation agrees with other
browsers. I have been advocating for the use of web standards since the birth of
the World Wide Web though only in my little corner of the world. And I expect
the specs has been discussed in depth in many forums not just related to the
Mozilla Project. But if the discussions have let to a shared misinterpretation
of the specs a new discussion is called for. Whether this is the case or not I
don't know but is stating to suspect so. Need more info to compute ...
I don't want to start a bugspam similar to the one about using the alt-attribute
as tooltip (Bug 25537, Keep it WONTFIX).
Which newsforums/irc channels can be used for this discussion? And is there a
archive of the earlier discussions I can dig in to? Whether my arguments are new
or not I don't know, but there s only one way to find out ... now where did I
put the datamining equipment ...?
BTW:
Boris: Thank you for your comment on the test cases in comment #7. Any comments
on the way I did them? Should I follow the same recipe on later test case uploads?
|
|
||
Comment 11•23 years ago
|
||
A good place to start is the www-style@w3.org archives
(http://lists.w3.org/Archives/Public/www-style/). Another decent place is the
netscape.public.mozilla.style newsgroup (on news.mozilla.org if nowhere else).
The chances that this is a shared mis-interpretation is kinda slim, since the
people who wrote the spec also wrote the code in this case... The current
behavior is basically designed for documents where you may want to do something
like:
section { margin: 2em 0; }
p { margin: 1em 0; }
<section>
<p>text 1</p>
<p>text 2</p>
</section>
<section>
<p>text 3</p>
<p>text 4</p>
</section>
In this case the amount of space that would make the most sense between "text 2"
and "text 3" is 2em, which signals a section break...
It may be worth starting a discussion on www-style@w3.org about this behavior..
the current CSS3 draft is at
http://www.w3.org/TR/2001/WD-css3-box-20010726/#collapsing if you want to take a
look and if you make a good case for a change to this behavior (or a property to
control it) it could well be modified accordingly.
|
||
Updated•23 years ago
|
QA Contact: petersen → moied
You need to log in
before you can comment on or make changes to this bug.
Description
•