Closed
Bug 222964
Opened 21 years ago
Closed 20 years ago
div with overflow auto doesn't respect vertical overflow boundaries set by surrounding table
Categories
(Core :: Layout: Tables, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mozilla, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
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•21 years ago
|
||
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•21 years ago
|
||
IE apparantly has the same problem BUT with the horizontal version. The vertical version does apply a scroll bar :)
|
||
Comment 3•21 years ago
|
||
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•21 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.
|
|
||
Comment 5•21 years ago
|
||
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•21 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•21 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
wfm winxp 2004092206 Christophe could you please retest with a recent nightly or 1.8.4a?
closing as wfm as nobody did oppose the wfm from september
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•