52063 - Overflowed data shouldn't resize page. (I think)

Status: VERIFIED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Brian 'netdragon' Bober]

Look at the URL. The first box (red) resizes the page only on Mozilla (adding a 
scroll bar), not IE. The second box resizes on both. 

http://www.w3.org/TR/1998/REC-CSS2-19980512/visudet.html

I looked at the standard, and I believe that on the first one, the part that is 
overflowed shouldn't determine page size because it is outside the ancestor's 
containing block. Note that when I changed position to relative for the 
descentant, the page wasn't enlarged.

On the second one, the descendant is again outside the parent's containing box 
(and overflowed), and the parent is moved to near the bottom of the page (but 
since it is 0 width, 0 height, the parent doesn't extend out of the page (its 
containing block) and the parent has overflow hidden - so the page shouldn't be 
enlarged.

I find the standard doesn't talk about enlarging the page, but since the 
descendant is contained within the ancestor, and the ancestor is within the 
boundary of the page, then the initial Containing block shouldn't be enlarged.

Also - I have a question about clipping. Since when you clip an element, its 
containing block stays the same size, it should still reserve the same amount of 
space, right?

Note that in IE, the second block (light blue) is colored in. I believe it 
shouldn't be, and Mozilla was correct, because it exceeded the bounds of the 
containing block. Is that correct?

I think the initial containing block should only be enlarged when its immediated 
descendant overflows. What do you think? Or do you think that someone should 
define the size of the body tag if they don't want the page to be enlarged. 
Notice that if I defined the width and height of the body, and the max-width and 
max-height and set overflow to hidden, the page was still enlarged.

Comment 1

[Chris Petersen]

Reassigning to chrisd

Comment 2

[Hixie (not reading bugmail)]

Layout issue -> buster. cc'ing dbaron in case he is more awake than I am
and so can work out if this is valid or not. I'll get to it eventually
if you don't. ;-)

Taking QA.

Comment 3

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

I don't agree with all of the comments above, but I agree that our behavior
seems wrong in the left example, but not the right one (although I'm not going
to look at the spec or the testcase in detail right now).  I tend to think that
the concept of having overflow should propogate outwards, but only through
elements with 'overflow: visible' (or whatever the new solution for the
never-published redefinition of clip that only Troy seemed to know anything about).

Confirming since I think there is something wrong here, although we need to
discuss further exactly what it is.

Comment 4

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

Also filed bug 57617 on this testcase.

Comment 5

[buster]

P3 -> Future.

Comment 6

[Hixie (not reading bugmail)]

The first box shouldn't increase the viewport's scrollbar, because the overflow
is contained within its parent by 'overflow:hidden', but the second should
because it actually overflow, like David said.

Comment 7

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

Assigning to myself because it's more useful than having on buster's list.

Comment 8

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

I think this is technically a duplicate of bug 46257 but I'd rather leave them
separate, at least for now...

Comment 9

[Anne (:annevk)]

The URI gives a 404 (removed). Marking this as a DUPLICATE of the WORKSFORME bug?

Comment 10

[Brian 'netdragon' Bober]

Attachment: The testcase

Here is the testcase again.

I don't mean to be a nitpicker, but you don't mark a bug that was confirmed 4
years ago as WORKSFORME. WORKSFORME is not really supposed to be used on
confirmed bugs unless it was just confirmed tentatively. This was seen by
enough people to be known to be a bug.

Comment 11

[Brian 'netdragon' Bober]

--> Fixed

This bug was obviously fixed somewhere down the road.

The testcase is still used by bug 57617, which still has not been fixed.

Comment 12

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

Sorry, if we don't know what fixed a bug, it's WORKSFORME.  (We could have an
additional WORKSNOW resolution, but we don't.)  We limit the use of FIXED to
bugs where we know what fixed the bug.