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)
Tracking
()
VERIFIED
INVALID
People
(Reporter: sneakyhybrid, Unassigned)
Details
Attachments
(1 file)
|
3.18 KB,
text/html
|
Details |
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.
Comment 1•20 years ago
|
||
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.
Comment 2•20 years ago
|
||
This belongs in Core Layout.
| Reporter | ||
Comment 3•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
Naturally I forgot to actually move it ... moving now
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
| Reporter | ||
Comment 5•20 years ago
|
||
(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.
Comment 6•20 years ago
|
||
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
| Reporter | ||
Comment 7•20 years ago
|
||
(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.
You need to log in
before you can comment on or make changes to this bug.
Description
•