If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

div with overflow auto doesn't respect vertical overflow boundaries set by surrounding table

RESOLVED WORKSFORME

Status

()

Core
Layout: Tables
RESOLVED WORKSFORME
14 years ago
13 years ago

People

(Reporter: Christophe VG, Unassigned)

Tracking

({testcase})

Trunk
x86
Linux
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807

a div with overflow set to auto only respects horizontal overflow boundaries set
by eg. a table surrounding it. in vertical sense it never uses its own overflow
scrollbar, but forces other elements to change their boundaries. even the "main"
scrollbar is activated in stead of the scroll bar of the div.

Reproducible: Always

Steps to Reproduce:
1. open new browser
2. see attached testcase

Actual Results:  
the div keeps growing in vertical sense

Expected Results:  
obey the surrouding boundaries and start showing a scroll bar (like it correctly
does for horizontal situation)
(Reporter)

Comment 1

14 years ago
Created attachment 133688 [details]
testcase showing both bad (vertical) en good(horizontal) behaviour

Testcase shows two situations: the vertical one and the horizontal one. The
vertical one keeps on growing, surpassing the 50% set by the surrounding table,
and even causing the browser to show its "main" scrollbar.
(Reporter)

Comment 2

14 years ago
IE apparantly has the same problem BUT with the horizontal version. The vertical
version does apply a scroll bar :)
Could you please clearly describe the expected behavior on that testcase and why
it's expected?  Further, is the behavior the same in standards mode and quirks
mode here?
(Reporter)

Comment 4

14 years ago
I would expect a viewport filling table dividing the viewport in four equally
big (50%x50%) panes, in which the upper-left pane would contain a horizontally
scrolling div and the lower-right pane a verticaly scrolling div.

I've tried the testcase in IE using HTML starting with <!DOCTYPE html PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN"> and with <!-- quirk on --> (If I
understand this quirk thingy correctly) but it doesn't make a difference. IE
doesn't start using a scrollbar as soon as the data inside the div starts to get
bigger than the 50% proposed by the surrounding table.
Note that layout here is identical if the overflow rule is removed... so the
real problem is that the first row is too short.
(Reporter)

Comment 6

14 years ago
euhm, that's the whole idea. The overflow should cover the fact that the content
is too large and start using scrollbars.

removing the overflow rule causes all content to be fully displayed and forces
the browser to show its "main" scrollbars.

IMHO the overflow rule actually works correctly on the first row, adding a
scrollbar for the data inside the upper-left pane because it is too big for this
pane.
(Reporter)

Comment 7

14 years ago
After some googling I came down with this solution to the IE part of the
problem. Appartly there is a CSS2 property called table-layout, which if set to
fixed forces a browser to obey the sizing constraints imposed by the table
definitions. So adding style="table-layout: fixed" to the outer table in the
testcase, results in IE rendering the table with the two panes scrolling as
expected.

http://www.w3.org/TR/REC-CSS2/tables.html explains it as:
CSS does not define an "optimal" layout for tables since, in many cases, what is
optimal is a matter of taste. CSS does define constraints that user agents must
respect when laying out a table. User agents may use any algorithm they wish to
do so, and are free to prefer rendering speed over precision, except when the
"fixed layout algorithm" is selected.

The article that lead me to this solutions was:
http://www-level3.experts-exchange.com/Web/Web_Languages/CSS/Q_20734395.html

Updated

13 years ago
Keywords: testcase

Comment 8

13 years ago
wfm winxp 2004092206 Christophe could you please retest with a recent nightly or
1.8.4a?

Comment 9

13 years ago
closing as wfm as nobody did oppose the wfm from september
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.