From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 BuildID: 2002031104 When calculating the actual pixel size for rendering an IMG or OBJECT from a percentage size, it appears that the size of the border and padding are not being taken into account. I have file full of testcases which I will attach. Reproducible: Always Steps to Reproduce: See attachment Actual Results: Border and padding escape the edge of the surrounding block Expected Results: IMG/OBJECT, border and padding should be entirely within the surrounding block.
Bug 131770 filed for OBJECT sizing problem mentioned in examples 2 and 3 of testcase. Adding testcase keyword to this bug. I'll file a bug for the redrawing problem mentioned in example 2 only if someone else can confirm it - I'm fed up of filing bugs now :-)
Confirmed, 2002-03-17-21 trunk nightly on Linux. (I get different results on example 2 and 3 though)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
*** Bug 129381 has been marked as a duplicate of this bug. ***
Also occurs for blocks like DIV so this is a general problem. Testcase with DIV: attachment 72891 [details] (from bug 129381)
Summary: IMG and OBJECT border and padding are not taken into account when calculating actual size from percentage size → Border and padding are not taken into account when calculating actual size from percentage size
"width" should not include border and padding. See the CSS2 specification.
So... The fact that this works as it does with the divs is very odd. I thought we just mapped "width" to the CSS property, but apparently not... resummarizing to make the issue clear (scroll all the way to the bottom of the testcase to see the block case).
Summary: Border and padding are not taken into account when calculating actual size from percentage size → Replaced inlines with borders/padding size differently from blocks when width="100%"
Changing QA contact
QA Contact: petersen → amar
Note that the testcase looks the same in strict mode, FWIW.
Aaaand more investigation shows that I just suck. The |width="100%"| on the <div> elements is simply ignored, since it's not a valid attribute for a <div> element. So the divs size based on |width: auto| and their sizing is correct given that. For replaced inline elements, we map |width="100%"| into CSS as |width: 100%| which means "the content width (not including padding or borders) should be the width of the containing block". As such, the sizing is correct. So I'd say this bug is invalid.
QA Contact: amar → ian
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
Re comment 6 - Boris, can you point me at the part of the CSS2 spec which says this? I've looked but can't find it, and I'd like to know the reasoning behind it. To me, the ignoring border and padding is counter-intuitive, and sure as hell *looks* like a bug, even if it actually isn't :-)
Component: Layout → XP Apps
http://www.w3.org/TR/REC-CSS2/visudet.html#the-width-property sez: > 'width' [...] This property specifies the content width of boxes generated > by block-level and replaced elements. The content of the box in this case is the image itself, and not its border or padding, which surround the content (see http://www.w3.org/TR/REC-CSS2/images/boxdim.gif). Therefore, I agree that the behaviour at the moment is technically correct, but I don't think it's *right*. I think this is a bug in the CSS2 spec - anyone agree? [Shouts of 'Stone the blasphemer' :-) ] How do we file a bug in CSS2?! So, what happens now? I don't really think it should be left - things like the testcase (particularly example B) are going to crop up occasionally (there's already one dupe for this), and people are going to think it's a bug in Mozilla - as I said, it sure as hell looks like one! I've just tried the testcase in IE5.5, and it renders the image and its padding and border entirely within the TD - anyone care to try it in other browsers (particularly IE6)? Should the technically-incorrect behaviour be added to 'quirks mode'?
So... the quirk you're suggesting is to default all replaced inlines to border-box sizing in quirks mode? That would be doable, but I'm not sure this fits the quirks mode criteria ("something that breaks many existing sites when done the right way"), since there aren't many sites affected by this issue.
Hmmmm, see your point, but I just think we need to do something! Hang on, correct me if I'm being thick here, but consider if, instead of setting width to a percentage, we set it to an absolute pixel size: <TABLE border="1" cellspacing="10"> <TR> <TD><IMG src="http://mozilla.org/images/mozilla-banner.gif" style="width: 100px; border: 10px solid red; padding: 10px"></TD> <TD><IMG src="http://mozilla.org/images/mozilla-banner.gif" style="width: 100px; border: 10px solid red; padding: 10px"></TD> </TR> </TABLE> Surely, this width should also only be applied to the image itself, therefore we would expect that these borders would also escape from the TD? However, they don't! Or am I missing something? Also, setting component back to Layout - I seem to have accidentally changed it. Finally, can anyone else see a difference between the first and second table cell in examples A and B? I see the image in the second cell 1px shorter (vertically), and a gap between the bottom border of the IMG (red/blue) and the bottom border of the TD (green). This is very strange, since the code is identical for these 2 cells! If you can't, try a different screen mode (I've got the window maximized at 1152x864). I also see a gap under both the IMG borders in example 3. The gaps seem to appear and disappear when I resize the window. This could just be my video drivers, but please can someone check?
Component: XP Apps → Layout
> Surely, this width should also only be applied to the image itself, therefore we > would expect that these borders would also escape from the TD? No, because now the <img> has a fixed size and the <td> sizing algorithm makes it shrink wrap the margins of the <img>. I'm not seeing the spacing problem you describe; it could well be resolution/DPI dependent.
I give up - the behaviour is technically correct, and I seem to be in a minority in believing that it's not the right thing to do ;-) Bug 132057 filed for the image sizing/gap problem.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.