Closed Bug 293608 Opened 20 years ago Closed 20 years ago

Fx103/Gecko - Padding values on PARENT containers cause its specified dimensions to expand improperly.

Categories

(Core :: Layout, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: sneakyhybrid, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; YPC 3.1.0; .NET CLR 1.1.4322)
Build Identifier: http://download.mozilla.org/?product=firefox-1.0.3&os=win&lang=en-US

After many tests, I have determined that Parent Containers with fixed width 
and height values are improperly resized based on the addition of padding 
values. This occurs with both HORIZONTAL or VERTICAL padding.  

The temporary fix is to subtract the total padding value from the lenght value 
either Horizontally or Vertically in order achieve the proper padding and KEEP 
the specified lenghts.

OR make the container A CHILD of a fixed width parent container.  And replace 
the CHILD's WIDTH and HEIGHT values with AUTO.


If width is 750px and height is not specified, adding 100px of PADDING-LEFT 
should NOT cause the container to grow beyond the viewport(or 850px).  It 
should cause CONTENT to shift right 100px BUT remain inside the 750px width 
specified.

This only happens with PARENT containers.  Child containers are restricted to 
the inside of their parents ONLY if their width is NOT specified(or AUTO)  



Reproducible: Always

Steps to Reproduce:
1. Create a parent container,  such as a DIV, then add a style attribute.
2. In the style attribute, specify WIDTH along with a UNIT(i.e. 100px). Then 
add padding-left of 10px.  
3. Write enough text to cause wrapping.

Actual Results:  
The padding specified is CLEARLY ADDED to the container's specified width. 
Let's pretend there was a background image that is exactly 100px wide for that 
DIV.  The text would overflow to the right 10px.  

Expected Results:  
The padding is supposed to stay INSIDE the 100px and not make the text box any 
larger.
Please add a testcase showing this issue please:
https://bugzilla.mozilla.org/attachment.cgi?bugid=293608&action=enter

You might also wanna test with a trunk build also:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Summary: Fx103/Gecko - Padding values on PARENT containers cause its specified dimensions to expand improperly. → Fx103/Gecko - Padding values on PARENT containers cause its specified dimensions to expand improperly.
This belongs in Core Layout.
Attached file Padding Tests
Seems like MOST people are misunderstanding PADDING specifications.  Maybe W3C
should be a little clearer on this.  Because over the last 7 years of coding, I
have used padding to position text inside a container, without resizing the
container.  For things such as MENUs with nice backgrounds.
Naturally I forgot to actually move it ... moving now
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
(In reply to comment #1)
> Please add a testcase showing this issue please:
> https://bugzilla.mozilla.org/attachment.cgi?bugid=293608&action=enter
> You might also wanna test with a trunk build also:
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

The padding test page looks the same in "latest-trunk" build I just downloaded.
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.1 (at
http://www.w3.org/TR/CSS21/visudet.html#the-width-property) 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, MacIE, Opera, and Safari, has two rendering modes -- your
page triggers the "BackCompat" mode in which its rendering is broken.  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.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
(In reply to comment #6)
> 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.1 (at
> http://www.w3.org/TR/CSS21/visudet.html#the-width-property) 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, MacIE, Opera, and Safari, has two rendering modes -- your
> page triggers the "BackCompat" mode in which its rendering is broken.  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.
> 

I got it now..  sorry for disturbing.  I re-read specification on "WIDTH" and
it's meaning.  Which enlightened me..  Thank you for the very useful link on the
box hack.
verifying resolution
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: