Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 5 of 5
  1. #1
    New Coder
    Join Date
    Feb 2007
    Posts
    15
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Divisions expanding in IE6 = bad

    Hey everyone. Once again, IE6 is turning its ugly head on some code with which I'm experimenting. My divisions are supposed to stack up in a nice little table-like set, and they work fine in Firefox. But Internet Explorer decides to make each division like a block. Any ideas?

    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html>
     <head>
      <title>Box Trouble</title>
      <style type="text/css">
       .div1 {overflow:hidden; _zoom:1; border: 3px solid black;}
       .div2 {float:left; border: 3px solid red;}
       .div3 {border: 3px solid green; height:30px;}
       .div4 {border: 3px solid blue;}
      </style>
     </head>
     <body>
      <div class="div1">
       <div class="div2">
        <div class="div3">Box1</div>
        <div class="div4">Box2</div>
       </div>
       <div class="div2">
        <div class="div3">Box3</div>
        <div class="div4">Box4</div>
       </div>
       Inside Big Box
      </div>
      <div>Outside Big Box</div>
     </body>
    </html>
    I've attached images of IE6 and FF renderings if yall don't have IE6 (linux/mac/vista).
    Attached Thumbnails Attached Thumbnails Divisions expanding in IE6 = bad-ie6_boxes.jpg   Divisions expanding in IE6 = bad-ff_boxes.jpg  

  • #2
    The fat guy next door VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    8,629
    Thanks
    6
    Thanked 1,002 Times in 975 Posts
    Well, don’t know who is wrong in this case but it looks like IE is doing it correctly as an exception.
    Since divs are block-level elements they have a width of 100% by default unless they are floated or absolutely positioned (or made display: inline;) - or you assign a specific width. And in your case you didn’t specify a width for the inner divs (class 3 and 4), and hence they are 100% wide. I think it’ll work if you give those inner divs a fixed width.

  • #3
    New Coder
    Join Date
    Feb 2007
    Posts
    15
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hmm, I can understand that. I don't know why Firefox isn't assuming div3 and div4 are 100%. It has something to do with the parent function (div2) being floated left. If you remove the float left comment, or even replace it with a block:inline parameter, Firefox will go back to assuming div3 & div4 are 100% width.

    My problem is that I don't know what will be inside the boxes, so I can't define their width. I would use a table, but I'm going to include some relative positioning and hover effects, too.

  • #4
    Senior Coder Arbitrator's Avatar
    Join Date
    Mar 2006
    Location
    Splendora, Texas, United States of America
    Posts
    3,300
    Thanks
    28
    Thanked 275 Times in 269 Posts
    I couldn’t find anything in the specification that precisely described the behavior. The below vagueness is from the CSS2.1 Working Draft.

    10.3.5 Floating, non-replaced elements

    If 'margin-left', or 'margin-right' are computed as 'auto', their used value is '0'.

    If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width.

    Calculation of the shrink-to-fit width is similar to calculating the width of a table cell using the automatic table layout algorithm. Roughly: calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur, and also calculate the preferred minimum width, e.g., by trying all possible line breaks. CSS 2.1 does not define the exact algorithm. Thirdly, find the available width: in this case, this is the width of the containing block minus the used values of 'margin-left', 'border-left-width', 'padding-left', 'padding-right', 'border-right-width', 'margin-right', and the widths of any relevant scroll bars.

    Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).
    I would note in the above that the behavior should be similar to that of tables; block level elements inside of table cells concede to the shrink‐to‐fit behavior of tables.

    I would guess that Firefox 2’s behavior is correct since Internet Explorer 7 and Opera 9 behave identically. Internet Explorer also seems buggy in that replacing the first (but not second) div element with a span element makes it behave like Firefox. Same thing if you remove the height applied to the same div elements.
    For every complex problem, there is an answer that is clear, simple, and wrong.

  • #5
    Senior Coder koyama's Avatar
    Join Date
    Dec 2006
    Location
    Copenhagen, Denmark
    Posts
    1,246
    Thanks
    1
    Thanked 5 Times in 5 Posts
    Quote Originally Posted by VIPStephan View Post
    Since divs are block-level elements they have a width of 100% by default unless they are floated or absolutely positioned (or made display: inline; )
    Although I think I know what you mean, this formulation may be confusing. The initial value of width is auto and not 100%. Often the two values will compute to the same result, but not always. If there at the same time is border or padding, width: 100% usually computes to a larger value that width: auto.

    Next, we are considering a div within an auto-width float. I believe that in such a case the div width would be undefined by CSS 2.1 if a percentage value was specified. This is because the containing block (the auto-width-float) itself has a width which depends on the nested div's width.

    Quote Originally Posted by Arbitrator View Post
    I couldn’t find anything in the specification that precisely described the behavior. The below vagueness is from the CSS2.1 Working Draft.
    [...]
    I would guess that Firefox 2’s behavior is correct since Internet Explorer 7 and Opera 9 behave identically. Internet Explorer also seems buggy in that replacing the first (but not second) div element with a span element makes it behave like Firefox. Same thing if you remove the height applied to the same div elements.
    While I'm not sure I understand that part in the specification either, I agree that we for now may assume that Firefox's rendering is correct and IE6's wrong.

    I believe that what you observed when you changed the div to a span may have to do with the span being inline-level, hence the height is ignored. As you noted, removing the height of the div fixes the problem. This suggests that it is caused by hasLayout being triggered. This indeed seem to be the case. Here is an example that shows what is going on. The issue has not really been fixed in IE7, but rather we now get what we would normally have expected in IE when hasLayout is triggered.
    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
    <html lang="en-Latn-US">
    <head>
    <title>IE6+7: auto-width-float > auto-width-non-float. Rendering issues when hasLayout is triggered on the nested div</title>
    <style type="text/css">
    html { background: white; color: black; font: 16px/1.2 sans-serif; }
    body { margin: 15px 15px 300px 15px; }
    dl { border: 1px solid black;	padding: 1em; }
    dt { font-weight: bold; }
    
    /* styles for illustrating the example */
    .lightgreen {
    	background: lightgreen;
    	width: 500px;
    	height: 200px;
    }
    .pink {
    	float: left;
    	height: 100px;
    	background: pink;
    }
    .lightblue {
    	background: lightblue;
    }
    .haslayout {
    	zoom: 1;
    }
    </style>
    </head>
    <body>
    <h1>IE6+7: auto-width-float > auto-width-non-float. Rendering issues when hasLayout is triggered on the nested div</h1>
    <p>The pink div is floated and has <code>width:auto</code>. The long word gives the float some width</p>
    <p>Inside this one is a light-blue non-floated div also having <code>width:auto;</code></p>
    <p>The ligth-green div is an ordinary div having <code>width:500px; height:200px;</code></p>
    
    <h2>Example 1: light-blue div does not have layout. Everything is fine in IE6 and IE7.</h2>
    <dl>
    <dt>Rendering in IE:</dt>
    <dd>In IE6 and IE7 render correctly</dd>
    </dl>
    <div class="lightgreen">
    <code>width:500px;</code><br>
    <code>heigth:200px;</code><br>
    <div class="pink">
    <code>float:left;</code><br>
    <code>width:auto;</code><br>
    some_text_to_give_the_pink_div_some_width
    <div class="lightblue"><code>width:auto;</code></div>
    </div>
    </div>
    
    <h2>Example 2: light-blue div with hasLayout. Causes expansion in IE6. Causes shrinking in IE7</h2>
    <p>What happens in IE when layout is triggered using <code>zoom:1</code>?</p>
    <dl>
    <dt>Rendering in IE:</dt>
    <dd>In IE6 the light-blue div expands in width. How wide does it become? Hard to say. Testing is needed, but in this case the light-green div is able to stop the expansion.</dd> 
    <dd>In IE7 the light-blue div width becomes shrink-to-fit. Although this clearly is incorrect rendering, this is not surprinsing in IE since this is what usually happens when layout is triggered also outside a float.</dd>
    </dl>
    <div class="lightgreen">
    <code>width:500px;</code><br>
    <code>heigth:200px;</code><br>
    <div class="pink">
    <code>float:left;</code><br>
    <code>width:auto;</code><br>
    some_text_to_give_the_pink_div_some_width
    <div class="lightblue haslayout"><code>width:auto; zoom:1</code></div>
    </div>
    </div>
    
    </body>
    </html>


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •