View Full Version : CSS problem with dl {background}
phoenixshade
02-18-2007, 01:30 PM
This works fine in IE7, but for the life of me I can't figure out why it doesn't work in FF2. Relevent portions are highlighted in red. I've cut out some of the code, but I've left the skeleton intact.
First the css:
#wrap {
width:80%;
border:solid 1px #666;
min-width:650px;
margin-left:9%;
}
#header {
padding:16px 0px;
}
#content {
width:100%;
}
.subnav {
width:78%;
list-style:none;
background:#BBB;
margin:0;
}
.submenu {
width:16%;
float:left;
}
.submenu a {
color:#FFF;
text-decoration:none;
padding:4px 8px;
display:block;
}
.submenu a:hover {
background:#999;
display:block;
}
#sidebar {
float:left;
width:22%;
}
#sidebar dl {
width:100%;
list-style:none;
}
#sidebar .menu {
width:100%;
}
#sidebar .menu a {
color:#CCC;
display:block;
}
#sidebar .menu a:hover {
background:#BBB;
color:#FFF;
display:block;
}
#main{
float:right;
width:77%;
}
#footer{
clear:both;
padding:1px 8px;
background:#EEE;
color:#888;
}
And here's the markup:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head>
<title>Jabberwocky</title>
<link rel="StyleSheet" href="common.css" type="text/css" />
</head>
<body>
<div id="wrap">
<div id="header">
<h1>Page Title</h1>
<h2>Page Subtitle</h2>
</div>
<div id="content">
<div id="sidebar">
<dl>
<dt class="menu"><a href="#">Item1</a></dt>
<dt class="menu"><a href="#">Item2</a></dt>
<dt class="menu"><a href="#">Item3</a></dt>
<dt class="menu"><a href="#">Item4</a></dt>
</dl>
</div>
<dl class="subnav">
<dt class="submenu"><a href="#">Item1.1</a></dt>
<dt class="submenu"><a href="#">Item1.2</a></dt>
<dt class="submenu"><a href="#">Item1.3</a></dt>
</dl>
<div id="main">
<h1>Article Heading</h1>
<h2>Article Subheading</h2>
<p>'Twas brillig, and all the slithy toves<br />
Did gyre and gimble in the wabe.<br />
All mimsy were the borogoves,<br />
And the mome rath outgrabe.
</p>
</div>
</div>
<div id="footer">
<p>Footer</p>
</div>
</div>
</body>
</html>
In Firefox, the background color on the <dl> does not render. It works just fine on the <dt>s on hover.
The <dl> is a horizontal menu. The effect I'm shooting for is to have the menu bar extend the full width of the content area even if the menu itself does not. I'm sure I could solve this by wrapping a <div> around the <dl> and style that, but I want to know if there's something wrong with the way I did this, or is this just a FireFox bug?
EDIT: I tried the <div> wrapper around the <dl> and it still didn't work...
Arbitrator
02-18-2007, 08:30 PM
A definition list (dl) element has two mandatory child elements: dt and dd. For every dt element, there must be at least one dd element. The dt element and groups of associated dd elements should appear in alternating order. Example:
<dl>
<dt>Term</dt>
<dd>Data</dd>
<dd>Data</dd>
<dt>Term</dt>
<dd>Data</dd>
</dl>
If this is inappropriate for what you’re doing, then you shouldn’t be using a definition list. I haven’t tested your code, so I can’t say whether or not this is the cause of the problem, however.
You have at least two other problems as well. If you’re displaying that XHTML page as HTML (to make it Internet Explorer‐compatible), you shouldn’t be since that’s prohibited for XHTML 1.1; use XHTML 1.0 Strict instead. The page is also missing the required XML namespace declaration. Example:
<html xmlns="http://www.w3.org/1999/xhtml">
jlhaslip
02-18-2007, 10:59 PM
Reference this code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Definition List Example</title>
<style type="text/css">
body{
margin: 0;
padding: 0;
background-color: #ffffff;
color: #000000;
}
a {
display:block;
}
dl{
text-align: center;
margin: 0 0 .5em;
width: 12em;
padding: 0;
border: 2px solid #dd6666;
background-color: #cccccc;
color: #000000;
}
dt {
margin: 0;
background-color: #dd6666;
}
dd {
margin: 0;
}
dl a:hover{
background-color: #6666dd;
color: #ffffff;
}
</style>
</head>
<body>
<dl>
<dt>Menu List Here</dt>
<dd><a href="#" title=" sbmenu1 page 1">sbmenu1 page 1</a></dd>
<dd><a href="#" title=" sbmenu1 page 2">sbmenu1 page 2</a></dd>
<dd><a href="#" title=" sbmenu1 page 3">sbmenu1 page 3</a></dd>
<dd><a href="#" title=" sbmenu1 page 1">sbmenu1 page 1</a></dd>
<dd><a href="#" title=" sbmenu1 page 2">sbmenu1 page 2</a></dd>
<dd><a href="#" title=" sbmenu1 page 3">sbmenu1 page 3</a></dd>
</dl>
<dl>
<dt>Second Menu Here</dt>
<dd><a href="#" title="sbmenu2 Page One">sbmenu2 Page One</a></dd>
<dd><a href="#" title="sbmenu2 Page Two">sbmenu2 Page Two</a></dd>
<dd><a href="#" title="sbmenu2 Page One">sbmenu2 Page One</a></dd>
<dd><a href="#" title="sbmenu2 Page Two">sbmenu2 Page Two</a></dd>
</dl>
<div>
<a href="#" title="sbmenu2 Page One">link outside the dl</a></div>
</body>
</html>
phoenixshade
02-19-2007, 02:27 AM
Thanks for your responses. So far no success. IE7 is fine; FF2 still has issues.
I know you probably have better things to do than fixing someone's code, so I've posted the page at http://mysite.verizon.net/phoenixshade3/staging/home.html (http://mysite.verizon.net/phoenixshade3/staging/home.html) so you can see what it's doing. The css is at http://mysite.verizon.net/phoenixshade3/staging/common.css (http://mysite.verizon.net/phoenixshade3/staging/common.css). I commented the area in question (in both files) with "PROBLEM HERE" to make it easy to find.
I've changed the <dl>s to <ul>s. That part was easy. No change in the rendering at all on either browser.
Next, I changed the DTD to XHTML 1.0 strict. The output on Firefox showed no change, but this apparently threw IE7 into quirks mode, which is not at all what I had in mind. The code validated without problems in XHTML 1.0 strict.
So now, I've gone back to an XHTML 1.1 doctype, and added the XML namespace declaration. I researched at w3c and the Web Standards Project and found no indicator of the prohibition that Arbitrator mentioned (could you possibly give me a link?), and the code validates as valid XHTML 1.1
I'm at a loss, and I'm back at square one. Any further help would be greatly appreciated. Thanks!
- Wil
Arbitrator
02-19-2007, 02:58 AM
Next, I changed the DTD to XHTML 1.0 strict. The output on Firefox showed no change, but this apparently threw IE7 into quirks mode, which is not at all what I had in mind. The code validated without problems in XHTML 1.0 strict.This shouldn’t be happening. Internet Explorer 7 even tolerates the presence of an XML declaration.
So now, I've gone back to an XHTML 1.1 doctype, and added the XML namespace declaration. I researched at w3c and the Web Standards Project and found no indicator of the prohibition that Arbitrator mentioned (could you possibly give me a link?), and the code validates as valid XHTML 1.1See the W3C Note XHTML Media Types (http://www.w3.org/TR/xhtml-media-types/#summary). While the key phrase is not “must not”, but rather “should not”, I think the bright red in the summary table indicates well enough that you shouldn’t do this.
I'm at a loss, and I'm back at square one. Any further help would be greatly appreciated. Thanks!The problem is that you did not clear the floated elements inside .subnav. Since the floats are not cleared, the container is rendered as if it has no content and the background appears as if it’s missing.
Related Resources (Copied/Pasted):
Containing Floats (http://www.complexspiral.com/publications/containing-floats/) explains how the float model works.
Clearing Space (http://css-discuss.incutio.com/?page=ClearingSpace) provides a list of methods that can be used to clear floated elements.
Example Solution:
.subnav { overflow: auto; }
I commented the area in question (in both files) with "PROBLEM HERE" to make it easy to find.<! PROBLEM HERE > appears using View Source, but that’s not a correctly formatted comment. It appears correctly when I use the Edit HTML command of the Web Developer extension, so I don’t know if the incorrect comment is author error or browser error.
phoenixshade
02-19-2007, 03:23 AM
I know it shouldn't be putting IE in quirks mode, but it nonetheless seems to. Things like #wrap {width:80%;margin: 10px auto;} stopped working when I changed the DTD. I'll look into the problem further.
As for the comment, that's a big "oops." Perhaps that's what threw IE into quirks mode.
In any event, thanks for the article on clearing floats. I forgot that float pulls the element out of normal flow and therefore doesn't expand the containing box. Temporarily assigning a 1px border to the ul confirmed that the box was indeed there with a height of zero.
Thanks again.
- Wil
EDIT: Adding overflow: auto; worked, but I'm not completely clear on why. Also, it was indeed the erroneous comment that put IE into quirks mode... I'm now using XHTML 1.0 Strict, and everything works properly. Thanks for your help, and I hope I can return the favor by helping others on this board.
Arbitrator
02-19-2007, 02:18 PM
EDIT: Adding overflow: auto; worked, but I'm not completely clear on why.The answer is provided in the Clearing Space resource of my last post; it quotes the CSS2.1 specification.
phoenixshade
02-19-2007, 02:49 PM
The answer is provided in the Clearing Space resource of my last post; it quotes the CSS2.1 specification.
Well, I only see where the Clearing Space article says that it works— not why it works. Specification 10.6.7 (http://www.w3.org/TR/CSS21/visudet.html#root-height) explains why my ul didn't expand to contain the li's— because they are floated elements inside of a floating container— but it makes no mention at all of overflow, or why it would correct this.
In the CSS2.1 specification (11.1.1, Overflow (http://www.w3.org/TR/CSS21/visufx.html#overflow)), the overflow property controls whether the overflowing contents are clipped or not, and if so whether the containing element gets scroll bars or not. (It goes on to say that the scroll behavior depends upon the user agent, but doesn't get any more specific than that.)
In any case, it worked on my page, and I thank you again for you help.
Arbitrator
02-19-2007, 03:20 PM
Well, I only see where the Clearing Space article says that it works— not why it works. Specification 10.6.7 (http://www.w3.org/TR/CSS21/visudet.html#root-height) explains why my ul didn't expand to contain the li's— because they are floated elements inside of a floating container— but it makes no mention at all of overflow, or why it would correct this.I just looked it over and it seems that it does, just not in such a straight‐forward way.
This section applies to:
Block-level, non-replaced elements in normal flow when 'overflow' does not compute to 'visible' (except if the 'overflow' property's value has been propagated to the viewport).
'Inline-block', non-replaced elements.
Floating, non-replaced elements.
If 'margin-top', or 'margin-bottom' are 'auto', their used value is 0. If 'height' is 'auto', the height depends on the element's descendants (http://www.w3.org/TR/CSS21/visudet.html#root-height).
For 'inline-block' elements, the margin box is used when calculating the height of the line box.
The default value for the height property is auto. The hyperlink reference “depends on the element’s descendants” refers to section 10.6.7.
In certain cases (see the preceding sections), the height of an element is computed as follows:
If it only has inline-level children, the height is the distance between the top of the topmost line box and the bottom of the bottommost line box.
If it has block-level children, the height is the distance between the top margin-edge of the topmost block-level child box and the bottom margin-edge of the bottommost block-level child box.
Absolutely positioned children are ignored, and relatively positioned boxes are considered without their offset. Note that the child box may be an anonymous block box.
In addition, if the element has any floating descendants whose bottom margin edge is below the bottom, then the height is increased to include those edges. Only floats that are children of the element itself or of descendants in the normal flow are taken into account, e.g., floats inside absolutely positioned descendants or other floats are not.
phoenixshade
02-20-2007, 12:16 AM
I just looked it over and it seems that it does, just not in such a straight‐forward way.
In addition, if the element has any floating descendants whose bottom margin edge is below the bottom, then the height is increased to include those edges. Only floats that are children of the element itself or of descendants in the normal flow are taken into account, e.g., floats inside absolutely positioned descendants or other floats are not.
The default value for the height property is auto. The hyperlink reference “depends on the element’s descendants” refers to section 10.6.7.
I saw this, but I'm not sure I agree with your interpretation. You put an emphasis on the statement above about the element height, but the next sentence is key to my interpretation: "Only floats that are children of the the element [...] in the normal flow are taken into account, e.g., floats inside [...] other floats are not."
In my example, the floating element (the <li>) is inside of another floating element (the <ul>). If your interpretation was correct, then overflow:auto would not be needed, as the <ul> would automatically expand its height to contain the floating <li>. (I've now learned that IE7 does this, but standards-compliant browsers apparently do not.)
BTW, I hope you don't think I'm attacking your expertise. I'm just trying to bring my coding to the "next level" so to speak, and it helps me to understand things more concretely when I discuss them with other knowledgeable folks such as yourself.
___________________
EDIT: Ahh, I think I see the light... in this stippet of XHTML:
<div id="level1" style="float:right">
<div id="level2" style="float:left">
<div id="level3" style="float:right">
<p>Some Content Here</p>
</div>
<div>
<div>
The height of #level1 would be expanded to include the margins of #level2 (child of the element itself), but not those of #level3 (child of a descendant that is not in the normal flow). So it appears that in my case, IE7 was actually doing the standards-compliant thing, but FF2 was not.
This also leads to another question: by the same reasoning, shouldn't #level2 expand to include the bottom margin of #level3 (child of the element), which means in turn the #level1 would expand as well to include the bottom margin of its child, #level2? I guess this would depend on whether the algorithm for resolving height works from the inside out (as IE7 appears to) or from the outside in (as FF2 seems to). Do the standards specify which type of algorithm is correct?
vBulletin® v3.8.2, Copyright ©2000-2012, Jelsoft Enterprises Ltd.