131768 - Replaced inlines with borders/padding size differently from blocks when width="100%"

Status: VERIFIED INVALID

(Core :: Layout, defect)

Description

[Russell Odom]

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.

Comment 1

[Russell Odom]

Attachment: Testcases

Various examples of this bug

Comment 2

[Russell Odom]

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 :-)

Comment 3

[Mats Palmgren (inactive)]

Confirmed, 2002-03-17-21 trunk nightly on Linux.
(I get different results on example 2 and 3 though)

Comment 4

[Mats Palmgren (inactive)]

*** Bug 129381 has been marked as a duplicate of this bug. ***

Comment 5

[Mats Palmgren (inactive)]

Also occurs for blocks like DIV so this is a general problem.
Testcase with DIV: attachment 72891 [details] (from bug 129381)

Comment 6

[Boris Zbarsky [:bzbarsky]]

"width" should not include border and padding.  See the CSS2 specification.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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).

Comment 8

[Christine Hoffman]

Changing QA contact

Comment 9

[Christopher Hoess (gone)]

Note that the testcase looks the same in strict mode, FWIW.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.

Comment 11

[Hixie (not reading bugmail)]

I agree.

Comment 12

[Russell Odom]

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 :-)

Comment 13

[Hixie (not reading bugmail)]

Russel: http://www.w3.org/TR/REC-CSS2/box.html#box-dimensions

Comment 14

[Russell Odom]

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'?

Comment 15

[Boris Zbarsky [:bzbarsky]]

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.

Comment 16

[Russell Odom]

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?

Comment 17

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 18

[Russell Odom]

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.