Closed Bug 324406 Opened 19 years ago Closed 19 years ago

Incorrect layout of div elements

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: swhitehead, Unassigned)

Details

Attachments

(1 file)

testcase from bug
480 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

While attempting to author a new layout, I found that the following code produced unusual results

<div style="width: 800px; height: 600px; border: solid 1px #000000;">
  <div style="border-bottom: solid 1px #cccccc;">Header</div>
  <div style="width: 100%; height: 100%">This is the content</div>
  <div style="border-top: solid 1px #cccccc;">Footer</div>
</div>

The intention is that the boudning div should be a "minimum" of 800x600 pixels, the header and footer should appear at the top and bottom of this area and the content area should take up the remaining space.

When previewed, the lower div (footer) appears OUTSIDE the bounding div's area (it is rendered out side of the border)

Expected output;
-----------
| header  |
|---------|
| content |
|         |
|         |
|---------|
| footer  |
|---------|

Actual output;
----------- { Bounding outter div starts }
| header  |
|---------|
| content |
|         |
|         |
|         |
|         |
|---------| {Bounding out div ends }

 ---------
  footer

The preview was attempted in IE and it produced the expected results (I would agree that this is not always a good comparison)

I am able to produce the desired results by using <table> elements

<table style="width: 800px; height: 600px; border: solid 1px #000000;">
  <tr>
    <td style="border-bottom: solid 1px #cccccc;">Header</td>
  </tr>
  <tr>
    <td style="width: 100%; height: 100%">Content</td>
  </tr>
  <tr>
    <td style="border-top: solid 1px #cccccc;">Footer</td>
  </tr>
</table>

The is using <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> as it's doc type

Reproducible: Always

Steps to Reproduce:
Enter the code into a basic page and display
Actual Results:  
The page was rendered incorrectly

Expected Results:  
The inner divs should be rendered within the bounding area of the outter div.

The content div should occur the remaining space left over from the header and footer divs
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
This looks pretty much like a dup of the (invalid) bug 213707 to me...
Attached file testcase from bug — 

    
    

    
  
The rendering is exactly what the code is asking for 100% of 600px are 600px not a single px less. Tables do their special thing. 

>produced the expected results

Expected by reading the CSS2.1 spec? http://www.w3.org/TR/CSS21/visudet.html#the-height-property
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID

    
    

    
  
(In reply to comment #3)
> The rendering is exactly what the code is asking for 100% of 600px are 600px
> not a single px less. Tables do their special thing. 
> 
> >produced the expected results
> 
> Expected by reading the CSS2.1 spec?
> http://www.w3.org/TR/CSS21/visudet.html#the-height-property
> 

With respect, it would still seem invalid to allow any block element to extend beyond the parent element.

The intention here is to allow the "content" element to fill the remaining space  of the parent element, where the "header" and "footer" element heights are unknown.

I would expect the physical height of the "content" element to be 100% - (total height of all other elements within the block), ensuring the all elements fitted into the parent block.

While I'd admit this method could be considered a "hack" or lazy, unless you know of better way, I would argue that it is a resonable solution.

Even if this behaviour is, as you say, correct, shouldn't the containing block then "overflow"?  The footer element should now either be hidden (correct me if I'm wrong on the default overflow setting) or the parent element should display scroll bars NOT display the footer element beyond it's bounds

As specified by the CSS standard for containing blocks.
http://www.w3.org/TR/CSS21/visuren.html#containing-block

Either way, this behaviour is incorrect, produces unexpected results & looks bad.

Given that users are capable of changing many the underlying height properties of elements (particularly fonts), it is not going to be pratical to ever be able to provide a physical height value to all elements.

By "cheating" in the fashion I have, I was expecting to be able to say that the "content" element should fill all the remaining area of the containing block after all other elements have been resolvled (ie those with pixel attributes).

I would also agree with Bernd, that his interpretation of the CSS standard is correct, from his stand point, but I could interpret it to my point, as the height of the element is determined from the containing element, but at what point??  Before, after during the layout???

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: