Bug 13213 - "overflow: hidden" does not correctly overflow for elements with "white-space: nowrap" in tables
Summary: "overflow: hidden" does not correctly overflow for elements with "white-space...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
URL: http://www.lucasnewman.com/webkit/whi...
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2007-03-27 20:05 PDT by Lucas Newman
Modified: 2010-06-17 19:29 PDT (History)
5 users (show)

See Also:


Attachments
Reduced testcase showing the behavior. (1.82 KB, text/html)
2007-03-30 22:06 PDT, Lucas Newman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lucas Newman 2007-03-27 20:05:31 PDT
"overflow: hidden" does not correctly overflow for elements with "white-space: nowrap" inside table columns.

The expected behavior is for an element to clip to the viewport and not display the overflow.  However, instead, it expands the viewport to be as large as the full element and adds a scrollbar to the window.

I've put up a sample page which illustrates the problem.  The sample correctly clips the first element to the viewport with hidden overflow in Firefox 2.0.0.3 and IE 7.

<radr://problem/5093711> WebKit does not hide overflow for elements with "white-space: nowrap" in tables
Comment 1 David Kilzer (:ddkilzer) 2007-03-27 21:34:44 PDT
Confirmed with a local debug build of WebKit r20544 with Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135).

Comment 2 Lucas Newman 2007-03-27 21:56:53 PDT
A workaround is to set "display: block" on the table.
Comment 3 Lucas Newman 2007-03-27 22:01:40 PDT
Sorry, the workaround is actually: "table, tbody, tr, td { display: block; }"
Comment 4 Lucas Newman 2007-03-30 22:04:59 PDT
That workaround doesn't actually fix all cases.  I have updated the reduced testcase to take out the table border spacing, so the boxes on the top and bottom can be directly compared (they should be identical).
Comment 5 Lucas Newman 2007-03-30 22:06:58 PDT
Created attachment 13900 [details]
Reduced testcase showing the behavior.
Comment 6 Maxwell Terpstra 2010-06-17 19:29:13 PDT
This is not a bug.

The first part of the test case involves a table using auto layout mode.  In this mode, the width of the table is determined by the width of the cell content.  The width of the cell content must be calculated using a "shrink-to-fit" algorithm, since the normal algorithm depends on the width of the containing block being pre-determined.  The shrink-to-fit algorithm never results in overflow.

The second part of the test case does not use the shrink-to-fit width algorithm.  Instead, its width is determined solely by the width of its containing block (the viewport), irrespective of its content.  The calculated width ends up being less than the intrinsic width of the content, so overflow occurs.

If you want to prevent this kind of "overflow" (actually just width ballooning) in a table, use the fixed table layout mode.