Using 3/11 build on Win 95, Win NT, Win 98, Linux, and Mac8.5. Open the URL. A PRE element tag containing text is assigned a style of "border=solid". Expected result: Text in PRE element tag should be contained within border. Actual result: Text in PRE element tag runs outside of the border. This bug occurs in the original window that Apprunner brings up. It creates a scrollbar at the bottom, and if you scroll, the text runs out of the border box. If you maximize the screen, the text is contained within the box, but if you then minimize, the same bug behavior occurs.

Tried this test with other block-level elements such as BLOCKQUOTE, CENTER, H1, and PARAGRAPH. These render properly.

According to the CSS spec, section 10.3, block elements (the PRE in this case) are sized based on very specific rules. In this case the block element has children that are larger than it. We now conform to the spec (we didn't use to). It is, however, a compatability bug.

Unless there are any important pages that this breaks, I *strongly* suggest that we mark this bug INVALID.

in my opinion, this bug should be marked INVALID, as well. However since then, I am at least setting the status to the [TESTCASE] standard, one position less on the list, and chrisd@netscape.com'S bug report is complete.

OK, I agree now that this bug is invalid in terms of the specs - should it continue to be open as a compatibility bug?

I would say lets close it; this surely doesn't break many pages, does it? This is not a serious issue, and I am sure there are better things for Kipp to be working on. [;-)] However, I'll leave this up to Kipp, since he was the one who suggested it be made a compat bug in the first place.

I'm not going to fix this compatability issue because the trigger for the "bug" is css style on the pre tag. Nav 4.x's handling of css is a known mess so there is no point in emulating that mess.

Verified WONTFIX

I'm confused. Some blocks can have children larger than themselves? (I'm not very familiar with the specs.) Anyway, the testcase I just attached doesn't seem to have nested elements.

Yes, some blocks can have children bigger than themselves, for example: <div style="width: 10em"> <div style="width: 20em"> </div> </div> In this case, the <pre> has text that is bigger than the box. Thus the text overflows the box. In CSS very few boxes are actually sized by their contents, the only exceptions I can think of being table elements, auto-width floats, and marker boxes. width:auto for an in flow block like this <pre> means "be the size of your parent's content area".

Does that also apply to my testcase, which uses white-space: pre on the same div element that has the border?

Yes, 'white-space:pre' has no effect on width in the constrained case. (The unconstrained cases being a floated element with 'width:auto', a cell in a table with 'width:auto', or an absolutely positioned element with 'width:auto' and at least one of 'right' or 'left' being 'auto', I believe. An in-flow block with width:auto _is_ constrained, since the width is replaced with the content width of the parent element after taking margins and padding of the block into account.)

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

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