Bug 8735

Summary:

CSS 2.1 visibility: collapse rendered as visibility: hidden

Product:

WebKit

Reporter:

Joost de Valk (AlthA) <joost>

Component:

Tables

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED CONFIGURATION CHANGED

Severity:

Major

CC:

arpitabahuguna, bdakin, browserbugs2, cascade, dbates, ddkilzer, dgrogan, edwardjsabol, emn13+webkit, ggaren, hyatt, ian, joysyu, karlcow, koivisto, maros.ivanco, mitz, mrowe, ntim, pravind.2k4, pyther, rc, reeets, regmeplease, robburns1, robert, webkit-bug-importer, webkit.bugzilla, webkit, zalan

Priority:

Keywords:

BrowserCompat, HasReduction, InRadar, WPTImpact

Version:

420+

Hardware:

Mac

OS:

OS X 10.4

URL:

http://www.quirksmode.org/css/visibility.html

Bug Depends on:

295479

Bug Blocks:

186131, 257336

Attachments:

Description	Flags
testcase	none
Improved testcase	none
[WIP] Collapsing rows and row groups	none
[WIP] Collapsing rows and row groups	none
testcase	none
rendering in safari, firefox, chrome	none

Joost de Valk (AlthA)

Reported 2006-05-04 11:43:12 PDT

As you can see in the testcase on the url above, WebKit renders no visual difference between visibility: hidden and collapse, which it should. I will mail the owner of the site above if we can include his testcase in our testsuite.

Attachments
testcase (375 bytes, text/html) 2006-05-05 01:16 PDT, Joost de Valk (AlthA)	no flags	Details
Improved testcase (372 bytes, text/html) 2006-05-05 01:47 PDT, Joost de Valk (AlthA)	no flags	Details
[WIP] Collapsing rows and row groups (11.07 KB, patch) 2007-07-13 09:39 PDT, mitz	no flags	Details Formatted Diff Diff
[WIP] Collapsing rows and row groups (12.41 KB, patch) 2007-10-18 15:51 PDT, mitz	no flags	Details Formatted Diff Diff
testcase (1.78 KB, text/html) 2025-06-25 00:58 PDT, Karl Dubost	no flags	Details
rendering in safari, firefox, chrome (1.10 MB, image/png) 2025-06-25 01:12 PDT, Karl Dubost	no flags	Details
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Joost de Valk (AlthA)

Comment 1 2006-05-05 01:16:46 PDT

Created attachment 8120 [details] testcase

Joost de Valk (AlthA)

Comment 2 2006-05-05 01:47:06 PDT

Created attachment 8122 [details] Improved testcase

Joost de Valk (AlthA)

Comment 3 2006-05-05 01:47:55 PDT

The testcase should show a 100x100 green rectangle. This means that the second (red) row should collapse, while the table still maintains the width of 100px.

Joost de Valk (AlthA)

Comment 4 2006-05-05 01:53:17 PDT

Equivalent KHTML bug: http://bugs.kde.org/show_bug.cgi?id=126778

David Kilzer (:ddkilzer)

Comment 5 2006-07-02 03:40:27 PDT

*** Bug 9676 has been marked as a duplicate of this bug. ***

Gérard Talbot (no longer involved)

Comment 6 2007-06-24 11:52:31 PDT

Global testcase for visibility: collapse support: https://bugzilla.mozilla.org/attachment.cgi?id=147933

mitz

Comment 7 2007-07-13 09:39:21 PDT

Created attachment 15501 [details] [WIP] Collapsing rows and row groups I started working on collapsing rows and row groups, and here are some issues that I ran into: 1. Cells that span both collapsed and visible rows: 1.1. This is more of an odd consequence of the CSS 2.1 WD (why use the 'visibility' property for collapsing table parts?!): 'visibility' is an inherited property, so all the cells in a collapsed row inherit 'visibility:collapse', which for table cells means the same as 'visibility:hidden'. This completely hides cells that start on a collapsed row but also intersect a visible row. You can override it by specifying 'visibility:visible' on such cells. 1.2. According to the WD, "[c]ontents of spanned rows and columns that intersect the collapsed column or row are clipped", but it does not say exactly how. It seems, though, that if you have a cell spanning rows 1-3 and row 2 is collapsed, you are not supposed to render the top part and bottom part of the cell and cut out the middle. On the other hand, you do not want to clip out the cell's top and bottom borders. Also, do you clip content that normally would overflow? What I did for now is clip vertically to the height of the visible rows, and try to keep as much of the content visible as possible by decreasing the extra top space if necessary (so when taking away height from the cell, first to go is the bottom extra space, then the top extra space, then finally the cell content height). I kept the border painting all around the cell. 2. Collapsed borders: What is the "cell above" a given cell for the purpose of determining that cell's top border if the row above is collapsed? Skipping over collapsed rows seems like it would result in more consistency, but consider a case where due to collapsing the row above a given cell, the "cell above" now has a thicker border, which pushes down on the content of the given cell, making it taller and thus going against the principle that collapsing does not affect table layout. The alternative is to allow the "cell above" to come from a collapsed row. This of course may result in borders that look like they came out of nowhere, and possibly in split borders, but I am leaning towards this alternative.

mitz

Comment 8 2007-10-18 15:51:27 PDT

Created attachment 16725 [details] [WIP] Collapsing rows and row groups More advanced version of the patch, still in flux and still limited to rows and row groups.

mitz

Comment 9 2008-01-22 21:07:26 PST

*** Bug 11071 has been marked as a duplicate of this bug. ***

Maros Ivanco

Comment 10 2009-01-13 05:01:59 PST

Just a general comment to visibility:collapse: - it is important because it does not fire re-layout - there already is the implementation in fx3, so there is a place to discuss and compare

Rüdiger Cordes

Comment 11 2009-07-05 02:22:27 PDT

Yes, when collapsing a row the "above cell" is a point to think over. When collapsing it would be nice not to get a bad design, but: the creator of the table is the master of his work. When he collapses a row he himself has to make sure the layout remains nice. He can do so by changing the border of the now "above cell". That should be the way to treat this problem? I have found that Firefox 3.0.11 isnt ready yet: https://macshot.de/html/invisibility.png because a column isnt handled like a row. Kind regards, Rüdiger Simple code for comparison: <html> <head> <title>visibility</title> </head> <body> <P>Browser: <?php echo $HTTP_USER_AGENT;?></P> <table border="0"> <tr><td width=140> <P><b>original<br>table</b></P> <table border="1"> <tr> <td>A1</td> <td>A2</td> <td>A3</td> </tr> <tr> <td>B1</td> <td>B2</td> <td>B3</td> </tr> <tr> <td>C1</td> <td>C2</td> <td>C3</td> </tr> </table> </td><td width=140> <P><b>row B has<br>visibility:collapse</b></P> <table border="1"> <tr> <td>A1</td> <td>A2</td> <td>A3</td> </tr> <tr style="visibility:collapse"> <td>B1</td> <td>B2</td> <td>B3</td> </tr> <tr> <td>C1</td> <td>C2</td> <td>C3</td> </tr> </table> </td><td width=140> <P><b>column 2 has<br>visibility:collapse</b></P> <table border="1"> <tr> <td>A1</td> <td style="visibility:collapse">A2</td> <td>A3</td> </tr> <tr> <td>B1</td> <td style="visibility:collapse">B2</td> <td>B3</td> </tr> <tr> <td>C1</td> <td style="visibility:collapse">C2</td> <td>C3</td> </tr> </table> </td></tr></table> </body> </html>

Edward Sabol

Comment 12 2009-11-04 15:18:38 PST

I'd love to see this bug get some attention from the WebKit developers. Would it help to split this bug into two, one for dealing with rows and rowgroups and another for columns and colgroups?

Matthew

Comment 13 2010-03-04 14:07:52 PST

I'm also hoping to bring some attention to the bug. Here is a test case of the bug: http://pyther.net/a/visibility.html Happens on Linux in Chromium, midori, and other webkit based browsers.

Uqbar

Comment 14 2010-08-27 03:22:51 PDT

No single opensource browser can render properly this tag properties: https://bugzilla.mozilla.org/show_bug.cgi?id=915 (12 year old!) https://bugs.kde.org/show_bug.cgi?id=50688 http://code.google.com/p/chromium/issues/detail?id=12094 I fear they all share the same code base. Fix one, fixes all.

David L

Comment 15 2012-07-08 07:47:57 PDT

This functionality works fine in IE 9 and Firefox 13. It did not work in IE 8 and not sure when it started working in Firefox and continues to not work in Chromium (or anything Webkit based). Think it's about time this gets some love. In my opinion, 6 years should be plenty of time to get this fixed up.

Eamon Nerbonne

Comment 16 2012-11-21 05:39:48 PST

I just tested this on IE8 on Windows XP SP2 - it *does* support visibility collapse on table rows as expected, as does Opera (v12.10 tested on windows 7). That means that virtually all non-webkit browsers support this and have for a long time. It's also the only way to toggle row visibility without the visual "jumpiness" display:none entails (not to mention issues with rowspan).

Joy

Comment 17 2017-07-27 17:12:58 PDT

I'm interested in working on this :) Would it be okay to just submit a patch for visibility:collapse on rows & row spans?

Antti Koivisto

Comment 18 2017-08-09 00:15:06 PDT

Great! I don't know the details of this but if it matches the specified behavior and other browsers, sure.

Radar WebKit Bug Importer

Comment 19 2022-06-05 03:04:47 PDT

<rdar://problem/94402176>

Tim Nguyen (:ntim)

Comment 20 2022-06-05 03:07:20 PDT

There are a bunch of WPT for which Safari has a lower score because of this: https://staging.wpt.fyi/results/css/css-tables?label=master&label=experimental&aligned&q=visibility-collapse

Karl Dubost

Comment 21 2025-06-25 00:58:27 PDT

Created attachment 475648 [details] testcase A simple testcase

Karl Dubost

Comment 22 2025-06-25 01:12:59 PDT

Created attachment 475649 [details] rendering in safari, firefox, chrome Safari Technology Preview 26.0 (222) 20622.1.17 Firefox Nightly 141.0a1 14125.6.17 Google Chrome Canary 139.0.7258.2 7258.2

Karl Dubost

Comment 23 2025-08-16 08:36:18 PDT

Thanks to https://bugs.webkit.org/show_bug.cgi?id=295479 solved by Ahmad. We can close this one.

Note You need to log in before you can comment on or make changes to this bug.