251970 - horizontal padding is added to width, but this "feature" if not handled by container blocks

Status: VERIFIED INVALID

(Core :: Layout, defect)

Description

[Njc]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514

Objects having non-zero "width" and "padding" are displayed with a total extent
of width+padding, but this "feature" (that I personally call bug) not recognized
by containers (div, for example), resulting in a propagation of overflows.

Reproducible: Always
Steps to Reproduce:
1. open the page "http://www.thinking.it/bugs/widpad.html"

Actual Results:  
the border of "div", containing non-zero-width-padding elements, does not
contain it's inner elements.

Expected Results:  
"div" should calculate it's width in order to include all of it's inner
elements... (or the width-padding behaviour should be changed)

Comment 1

[Bill Mason]

That what's supposed to happen.  It's in the CSS specs.  The space the element
takes up equals its width+border+margin+padding.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Verified.

See section 4.1.2 of the CSS1 spec
(http://www.w3.org/TR/REC-CSS1#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'.

thus implying that "width" does not include border, padding, or
margin.  Further, CSS2 (at
http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-width) explicitly
says:

     This property specifies the content width of boxes generated by block-level
     and replaced elements.

And at http://www.w3.org/TR/REC-CSS2/box.html#box-dimensions the
specification pretty clearly says that "content width" means "not
including margin/border/padding".

Furthermore, see http://www.tantek.com/CSS/Examples/boxmodelhack.html.
This page was created by one of the members of the CSS working group,
who also happens to be the technical lead of the Mac IE team.  The
page describes what the correct behavior is and further illustrates a
hack to get IE5/Windows and IE5.5/Windows to do the right thing
(basically, by giving them rules that actually set the wrong width).
IE6, like Mozilla and MacIE, has two rendering modes -- your page
triggers the "BackCompat" mode in which its rendering is broken (due to the
presence of the XML declaration, which IE6 mis-parses).  In
its "CSS1Compat" mode it will render your page just like Mozilla does.
See
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/compatmode.asp
for more information on that.

Comment 3

[Njc]

(In reply to comment #2)

The bug that I was trying to explain is different: I was talking about the
container of the elements.


I have read specs: "http://www.w3.org/TR/REC-CSS1#horizontal-formatting", that says:
"By default, the 'width' of an element is 'auto'. If the element is not a
replaced element, this means that the 'width' is calculated by the UA so that
the sum of the seven properties mentioned above is equal to the parent width."

This mean that non-replaced container (parent ?) should enclose entirely the
contained elements.

*** IMPORTANT ***
I've changed the example on the page: http://www.thinking.it/bugs/widpad.html

It now shows that a "div" contains correctly a list and its items (even if
padded and forced to width=100%), but does not contain a similar "p" or "a" tag.
Why ?

Comment 4

[Njc]

(gulp!)
It seems that with 2 nested containers, inner elements will be rendered "pretty"
again, without overflows. 
(see example)

Comment 5

[Boris Zbarsky [:bzbarsky]]

> This mean that non-replaced container (parent ?) should enclose entirely the
> contained elements.

Not necessarily, no.  100% width means "width of container".  If you add padding
on top of that, the only way to render it is to overflow.

> It now shows that a "div" contains correctly a list and its items 

No, it does not contain them (though you're right about "correctly").  Put
borders or backgrounds on the list items like you did on the blocks in the other
float, please, to see the rendering.

> It seems that with 2 nested containers, inner elements will be rendered
> "pretty"

The "floating example" and "double packing" tests on that page render
identically in a current trunk Mozilla build.

Comment 6

[Njc]

(In reply to comment #5)
> No, it does not contain them (though you're right about "correctly").  Put
> borders or backgrounds on the list items like you did on the blocks in the other
> float, please, to see the rendering.

Yes, I misused the term "correctly"...
but it's hard to convince myself that "padding" is not part of the "width"...

Ok, thank you very much.