Bug 8735 - CSS 2.1 visibility: collapse rendered as visibility: hidden
: CSS 2.1 visibility: collapse rendered as visibility: hidden
Status: ASSIGNED
: WebKit
Tables
: 420+
: Macintosh Mac OS X 10.4
: P2 Major
Assigned To:
: http://www.quirksmode.org/css/visibil...
: HasReduction
:
:
  Show dependency treegraph
 
Reported: 2006-05-04 11:43 PST by
Modified: 2012-12-16 02:30 PST (History)


Attachments
testcase (375 bytes, text/html)
2006-05-05 01:16 PST, Joost de Valk (AlthA)
no flags Details
Improved testcase (372 bytes, text/html)
2006-05-05 01:47 PST, Joost de Valk (AlthA)
no flags Details
[WIP] Collapsing rows and row groups (11.07 KB, patch)
2007-07-13 09:39 PST, mitz@webkit.org
no flags Review Patch | Details | Formatted Diff | Diff
[WIP] Collapsing rows and row groups (12.41 KB, patch)
2007-10-18 15:51 PST, mitz@webkit.org
no flags Review Patch | Details | Formatted Diff | Diff


Note

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


Description From 2006-05-04 11:43:12 PST
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.
------- Comment #1 From 2006-05-05 01:16:46 PST -------
Created an attachment (id=8120) [details]
testcase
------- Comment #2 From 2006-05-05 01:47:06 PST -------
Created an attachment (id=8122) [details]
Improved testcase
------- Comment #3 From 2006-05-05 01:47:55 PST -------
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.
------- Comment #4 From 2006-05-05 01:53:17 PST -------
Equivalent KHTML bug: http://bugs.kde.org/show_bug.cgi?id=126778
------- Comment #5 From 2006-07-02 03:40:27 PST -------
*** Bug 9676 has been marked as a duplicate of this bug. ***
------- Comment #6 From 2007-06-24 11:52:31 PST -------
Global testcase for visibility: collapse support:
https://bugzilla.mozilla.org/attachment.cgi?id=147933
------- Comment #7 From 2007-07-13 09:39:21 PST -------
Created an attachment (id=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.
------- Comment #8 From 2007-10-18 15:51:27 PST -------
Created an attachment (id=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.
------- Comment #9 From 2008-01-22 21:07:26 PST -------
*** Bug 11071 has been marked as a duplicate of this bug. ***
------- Comment #10 From 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
------- Comment #11 From 2009-07-05 02:22:27 PST -------
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>
------- Comment #12 From 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?
------- Comment #13 From 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.
------- Comment #14 From 2010-08-27 03:22:51 PST -------
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.
------- Comment #15 From 2012-07-08 07:47:57 PST -------
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.
------- Comment #16 From 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).