151227 - CSS padding in a nested DIV with a fixed width causes overlap

Status: RESOLVED INVALID

(Core :: Layout, defect, P3)

Description

[Brian Sperlongano]

Mozilla 1.1a

If you make a nested div, with the outer div a fixed width and the inner div a
width:100% and padding > 0, the inner div will overlap the outer div.  

I have created a test case.

Comment 1

[Richard Brodie]

This is not a bug in Mozilla: the padding width is additional to the 100%. Older
versions of IE get this wrong.

Comment 2

[Bradley Baetz (:bbaetz)]

Browser, not bugzilla

Comment 3

[Brian Sperlongano]

This is indeed a bug.  According to the W3C's CSS2 Specification (URL: 
http://www.w3.org/TR/1998/REC-CSS2-19980512/box.html#padding-edge): 
 
The box width is given by the sum of the left and right margins, border, and 
padding, and the content width.  
 
Thus, content that is designated width:100% should fill it's container to 100% 
exactly with no overlap, including any padding/margin/border present. 

Comment 4

[bigendian]

http://www.w3.org/TR/REC-CSS1#block-level-elements

4.1    Block-level elements

The width of an element is the width of the content, i.e., the distance between
left inner edge and right inner edge. The height is the height of the content,
i.e., the distance from inner top to inner bottom. 

4.1.2    Horizontal formatting

The horizontal position and size of a non-floating, block-level element is
determined by seven properties: 'margin-left', 'border-left', 'padding-left',
'width', 'padding-right', 'border-right' and 'margin-right'. The sum of these
seven is always equal to the 'width' of the parent element. 

---

The 'width' attribute relates to the _inner_ space of a given block-level
element. I'm not quite sure if this is only a misconception or if it contradicts
the information in
http://www.w3.org/TR/1998/REC-CSS2-19980512/box.html#padding-edge (Comment #3).
But any element with width + padding/border/margin (>0) will overlap a parent
element with the same width. Anyway, IE is doing it one way, Mozilla the other
(according to REC-CSS1 correct) way now. This has to be solved soon!

Comment 5

[Brian Sperlongano]

4.1 and 4.1.2 seem to contradict each other.  4.1 says that width is just the 
content alone without mentioning border/padding/margin, whereas 4.1.2 says that 
width is the sum of all.  Does 4.1.2 supercede 4.1?

Interpreting it the former way would cause, at worst case, larger than expected 
paddings around elements.  If interpreted the latter way, at worst case, it 
would cause overlap.  Since overlap is by far the less-desireable unintended 
effect, I would say that border/padding/margin should be included in width.  
Additionally, it would seem to me impossible with CSS to make a 
border/padding/margin box fill an arbitrarily-sized containing box to the pixel 
if this were not the case.

Comment 6

[Brian Sperlongano]

CSS2 gives us some answers that were ambiguous in CSS1.  Comment #4 refers to 
the CSS1 specification.  In the CSS2 specification, at http://www.w3.org/TR/REC-
CSS2/box.html, two different widths are referred to: the *content width* and 
the *box width*.  The box width is the sum of content/padding/margin/border, 
while the content width is just the width of the inner content.  Thus, since a 
DIV tag is a box-model container, a width of 100% means a box width of 100%, 
which should fill it's parent container's content width to 100%.

This is supported by the following:

CSS2 defines "containing block":

  10.1§2 "...unless the element is absolutely positioned, the containing block 
is formed by the content edge of the nearest block-level ancestor box."

Also, and here's where it is spelled out precisely, when a contained box is 
specified as a percentage width:

  10.2 Content width: the 'width' property

  ...

  <percentage> 
  Specifies a percentage width. The percentage is calculated with respect to 
the width of the generated box's containing block. 

And,

10.3.3 Block-level, non-replaced elements in normal flow
...The following constraints must hold between the other properties:

'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-
right' + 'border-right-width' + 'margin-right' = width of containing block 

Thus, border/padding/margin must fall within the constraints of the content 
width of the parent.

Comment 7

[David Smith]

As a DIV, it follows the rules of
http://www.w3.org/TR/REC-CSS2/visudet.html#Computing_widths_and_margins - 
Section 10.3.3 Block-level, non-replaced elements in normal flow

The margins are 0 (default for auto), the paddings are set at 2px, and the width
at 100%.  This is an overconstrained situation, and to resolve it you follow
this rule:

'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right'
+ 'border-right-width' + 'margin-right' = width of containing block 

If all of the above have a specified value other than 'auto', the values are
said to be "over-constrained" and one of the computed values will have to be
different from its specified value. If the 'direction' property has the value
'ltr', the specified value of 'margin-right' is ignored and the value is
computed so as to make the equality true.

You start with:

auto + 0 + 2px + 100% + 2px + 0 + auto = 100%

Auto by default becomes 0, so:

0 + 0 + 2px + 100% + 2px + 0 + 0 = 100%

Since that's overconstrained, and this is an ltr document, this becomes

0 + 0 + 2px + 100% + 2px + 0 - 4px = 100%

Since the padding is drawn while the margin is transparent, the div overflows
its container.


10.2 Explicitly states that width "... specifies the _content width_ of boxes
generated by block-level and replaced elements."


Further, the draft proposal of the CSS3 box model specifically includes new
properties for the specification of box-width and box-height (width/height +
padding + borders) [currently with three different proposed mechanisms]
separately from content-width and content-height.  As such, I believe Mozilla's
behavior is correct (if occasionally frustrating), and this bug is INVALID.

Comment 8

[Brian Sperlongano]

Comment #7 Cites CSS2 - 10.3.3:

-begin quote-

10.3.3 Block-level, non-replaced elements in normal flow

If 'left' or 'right' are given as 'auto', their computed value is 0. The
following constraints must hold between the other properties:

'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right'
+ 'border-right-width' + 'margin-right' = width of containing block

-end quote-

This constrain MUST hold!  In essence, the CSS authors are saying that for this
type of box, the content CANNOT overflow!  This is not a constraint held upon an
HTML author, but rather a constraint held on a user agent that the generated
values of margin+padding+content cannot exceed that of the containing block. 
Thus, it would appear that the user agent must correct for "overconstrained"
formatting.  This document details HOW TO RENDER css documents, not how to write
them.

There is also a line about width = containing content width in section 10.2. 
The line is vague, and the exact implementation of it is laid out in section
10.3, so we cannot hold that the vague language of 10.2 holds precedence over
the specific language of 10.3.

The exact wording in 10.2 is "'width' - This property specifies the content
width of boxes generated by block-level and replaced elements. "

Clearly, this is intended to be a vague general description of the purpose of
the width property, not a specific rule of implementation as purported in
Comment #7,

Comment 9

[bigendian]

It is all about Quirk and Standard Modes. In Standard Mode both Mozilla (1.0)
and IE 6.0 render it the same way. That is, the width attribute denotes only the
innermost elements width. Padding, border, etc. has to be added for the overall
width of the block. That way this behavior is in conformance with the CSS1 and
CSS2 standard (at least as I understand it). (It should be noted that not all
standard references describe this circumstance clear enough.)

I didn't regard this as a bug in Mozilla in the first place, but as a big
problem for web designers, if Mozilla would render content that different from
the mainstream browsers. But I didn't know that IE 6.0 runs in Quirk Mode, when
there is a XML declaration at a documents beginning. That way IE was running in
Quirk Mode (despite the correct XHTML DOCTYPE declaration), while Mozilla was in
 Standard Mode with my test pages. (Well, I didn't know about different render
modes at all then.) With both browsers in the same mode the results are correct
now. (For both, standard and quirk mode.)

If correct, bug resolution should be changed to INVALID.

I found the following links to be very helpful:

CSS Enhancements in Internet Explorer 6
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp

Doctype switching and standards compliance: An overview
http://gutfeldt.ch/matthias/articles/doctypeswitch.html

Comment 10

[Boris Zbarsky [:bzbarsky]]

> This constrain MUST hold!

It does.  margin-right is negative in this case.  This bug is invalid.  The
description of "width" is not "vague" -- it is the definition of what the
"width" property actually means in the box model.