148527 - overflow:auto on body makes page disapearing

Status: RESOLVED DUPLICATE of bug 170040

(Core :: Layout, defect, P4)

Description

[Kai Lahmann (is there, where MNG is)]

duno, if I missed a techEvang-Problem or if this is really a Mozilla bug, but at
least it's strange.

Comment 1

[Kai Lahmann (is there, where MNG is)]

Attachment: testcase

added the full page as a testcase - if you remove the overflow:auto; in the
style, you'll see the page.

Comment 2

[Doron Rosenberg (IBM)]

emeyer, is this a product bug or an evang issue?

Comment 3

[Eric A. Meyer (dead account)]

Tough call.  By positioning all of the content in the BODY, the author has
removed everything from the normal flow of the document, thus making the
computed height of the BODY is zero-- and, in an 'overflow: auto' situation,
it's feasible that there would then be no way to access the content.  In fact,
there could be zero-height scrollbars on the 'body' element itself, but there's
no way to visually verify that.  (Can we find out via the DOM?)

Then again, 'auto' can mean "do what you like" and in this sort of situation it
might be a good idea for the product to recover gracefully in some fashion, like
treating the BODY as though it were the height and width of the browser window,
or maybe acting as though 'overflow' were actually set to 'visible'.  Basically,
we'll have to decide what's the best practice in such situations.  Then we'll
know whether this is a product bug or an evangelism issue.  CC'ing dbaron and
hixie, who ought to have a thing or two to say about this.

In the meantime, the author should in fact remove 'overflow: auto', or else set
it to 'visible'.  He could try setting 'height: 100%; width: 100%;' and doing
the same for the HTML element, but I don't know for certain that would work as
intended in both rendering modes.

Comment 4

[Hixie (not reading bugmail)]

sounds like an evang bug to me...

Comment 5

[Eric A. Meyer (dead account)]

Do you really think it's the best practice to suppress any overflowed content in
cases like this one?  If so, why?  I'm genuinely curious; I can't think of any
casees where doing the opposite would be a problem.

Granted we ought to evangelize a more sensible way to author, but I'd also like
to figure out if what Mozilla does here is more reasonable than, say,
interpreting 'auto' as 'visible' in such cases-- which the spec would let us do,
if we thought it a good idea.

Comment 6

[Hixie (not reading bugmail)]

Could you describe the exact conditions under which you propose we should treat
'auto' as 'visible' instead of 'scroll'?

#  auto
#    The behavior of the 'auto' value is user agent-dependent, but SHOULD cause a
#    scrolling mechanism to be provided for overflowing boxes.
   -- http://www.w3.org/TR/REC-CSS2/visufx.html#overflow

Comment 7

[Eric A. Meyer (dead account)]

Hmmm... how about in a case where an element has content, has been reduced to
zero height due to all of its content leaving the normal flow, and does *not*
have 'height: 0' explicitly set?

Comment 8

[Hixie (not reading bugmail)]

same thing.

Comment 9

[Hixie (not reading bugmail)]

(to clarify: the computed value of 'height' becomes 0. Since overflow is 'auto',
a scrolling mechanism of our choice is added, which happens to be scrollbars.)

Comment 10

[Garrett Smith]

11.1 Overflow and clipping

A box may overflow if it is positioned absolutely.

Overflow property specifies whether the content of a block-level element is
clipped when it overflows the element's box (which is acting as a containing
block for the content)
 --------------------------


The absolutely positioned of contents of the non-positioned body must be visible. 

The body is not the containing block for said contents. Said contents belong to
the initial containing block (ICB).

Comment 11

[Boris Zbarsky [:bzbarsky]]

dupping forward to bug with more relevant discussion....

*** This bug has been marked as a duplicate of 170040 ***