3701 - {compat} CSS: Text in PRE element tag is not contained within border

Status: VERIFIED WONTFIX

(Core :: Layout, defect, P3)

Description

[Christine Hoffman]

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.

Comment 1

[Christine Hoffman]

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

Comment 2

[kipp]

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.

Comment 3

[Hixie (not reading bugmail)]

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

Comment 4

[Christian Wenz]

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 [e-mail]'S bug report is complete.

Comment 5

[Christine Hoffman]

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

Comment 6

[Hixie (not reading bugmail)]

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.

Comment 7

[kipp]

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.

Comment 8

[Christine Hoffman]

Verified WONTFIX

Comment 9

[Jesse Ruderman]

Attachment: testcase based on a w3 page

Comment 10

[Jesse Ruderman]

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.

Comment 11

[Hixie (not reading bugmail)]

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

Comment 12

[Jesse Ruderman]

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

Comment 13

[Hixie (not reading bugmail)]

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

Comment 14

[Mats Palmgren (inactive)]

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

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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