155455 - Borders of a DIV are not rendered properly

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Justin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

When drawing the borders of an absolutely placed DIV, Mozilla only draws the
border of the DIV as far as the DIV height is specified. For example, if a DIV
is specified with a height=100, width=200 (as shown in the example URL), the
content of the DIV may cause the DIV to stretch vertically beyond it's defined
size. When this occurs, Mozilla stops drawing the DIV border at 100 pixels. 

Reproducible: Always
Steps to Reproduce:
1. Create an absolutely placed DIV
2. Define a border for the DIV using CSS
3. Put enough content in the DIV to exceed it's specified size

Actual Results:  Mozilla correctly renders the DIV but does not correctly draw
the border. 

Expected Results:  Mozilla should draw the border around the entire DIV. 

Please see provided URL.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> the content of the DIV may cause the DIV to stretch vertically beyond it's
> defined size.

No, it cannot.  The content can overflow the div; this is very easy to see if
you put "overflow: hidden" or "overflow: scroll" on the div.  In any case,
giving the div a pixel height means it must be that height.  See
http://www.w3.org/TR/REC-CSS2/visufx.html#overflow-clipping, the third bullet
item and fourth bullet item.

Also, please read the XP Apps component description; it has nothing to do with
layout of web content.

Comment 2

[Justin]

I don't think I've effectively communicated the issue. Did you take a look at
the provided URL? The issue is not that the content is clipped, the issue is
that the border of the stretched DIV is not drawn correctly, regardless of the
overflow attribute. 

Move it to another, more appropriate category if you prefer, but this is a real
issue. 

Comment 3

[Eric A. Meyer (dead account)]

It is a real issue-- the issue is that your styles call for this behavior, but
it isn't what you want.  After cleaning up the invalid CSS, one of your DIVs has
the following CSS:

position:absolute; z-index:1; left: 281px; top: 68px; width: 200px; height: 100px;

Great.  You've defined the element to be 200 pixels wide and 100 pixels high. 
It is.  The content spills out of the positioned element, but that's also
permissible in CSS2 (this is the situation described by 'overflow: auto').  In
CSS, the content of an element and its element box may not be the same size, and
you have in fact forced exactly that situation.

If your intent to to make sure the 'div' is never less than 100 pixels tall, but
more if need be, then you shoudl be using 'min-height':

position:absolute; z-index:1; left: 281px; top: 68px; width: 200px; min-height:
100px;

The bug shouldbe marked INVALID (as Boris did) because this is not a bug, it's
an example of what happens in a rendering engine that actually honors the rules
laid out in the CSS2 specification.  As it turns out, IE5/Mac does exactly the
same thing Mozilla does, which is to let the content of the top left and right
test DIVs exceed the borders when the text is too big to fit inside the explicit
widths you have set (use Text Zoom in either browser to see this).

Comment 4

[Justin]

Admittedly, I'm no expert but I don't think this is the intent of CSS2. If the
spec calls for the DIV borders to NOT expand when text overflows, Mozilla is
STILL doing it wrong - note in the example URL that I provided that the bottom
border of the DIV is never drawn when the content overflows the DIV. Where does
the spec say that the border should not be drawn at all in the case of overflow? 

Comment 5

[Boris Zbarsky [:bzbarsky]]

Sorry, but I did look at your testcase.  So I knew exactly what I was talking
about when I made my comment.  As I said, the <div> is not stretched; the
content just spills out of it.  The bottom border _is_ drawn.  If you look at
http://www.w3.org/TR/REC-CSS2/visuren.html#q30, it says that "Boxes with the
same stack level in a stacking context are stacked bottom-to-top according to
document tree order".  That means that you paint the parents, then you paint
their children in document order.  So in this case you have:

<div style="height: 100px; border: 1px solid black">
  <div style="background: blue">
     text<br>
     text
...
  </div>
</div>

The blue background must be painted _after_ the black border has been painted,
since children are painted after parents.  If you make that inner div "width:
50%" or something along those lines, so that it does not wholly cover up the
bottom border, you will be able to see this.

Re-marking invalid; the rendering is exactly correct.

Comment 6

[Eric A. Meyer (dead account)]

Actually, it's exactly the intent of CSS2.  Consider a situation where you want
an element to be exactly 200x100 pixels, and you want any "spillover" to
actually be cut off (maybe it would overlap other elements that you've also
positioned).  You'd write:

   <div style="position: absolute; height: 100px; width: 200px; overflow;
hidden;">...</div>

If you wanted to turn the 'div' into a little 'iframe'-like widget, you just
change 'hidden' to 'scroll' (or 'auto').  And if you want the content to keep
going past the boundaries of the element you explicitly sized-- well, you can do
that too, with 'overflow: visible'.  'visible' is the default value for this
property.

As for the bottom border not being drawn, that's because you set a background
color for the tables inside the positioned 'div' elements (.menutable
{background-color: #0099CC} ), and said background is overwriting the 'div'
border when the content overflows.  If you want to see the border, then don't
set a background color for the tables.  If you want to fill in the background of
the 'div' itself, then shift the background color off of the table and onto the
'div'.  The content will still overflow, but you should be able to see the border.

So far as I can see, Mozilla is honoring your styles precisely as it should--
and, as I say, IE5/Mac acts consistently with Mozilla in this testcase.  Given
my understanding of CSS2, which is not perfect but is fairly deep, both are
correct.  I'll cc: dbaron to see what he thinks, in case there are errata I'm
forgetting to take into account or I missed someting in the specification.  (It
happens, as both dbaron and hixie could testify.)

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The analysis in comment 6 is correct.

Also note that CSS2 has the 'min-height' and 'max-height' properties, which may
be useful for what you want to do.  (MSIE for Windows incorrectly treats the
'height' property in many cases as it should treat 'min-height'.)