Bug 8735 – CSS 2.1 visibility: collapse rendered as visibility: hidden

• Status: NEW
• Component: Tables

[Joost de Valk (AlthA)]

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.

[Joost de Valk (AlthA)]

Created attachment 8120 [details]
testcase

[Joost de Valk (AlthA)]

Created attachment 8122 [details]
Improved testcase

[Joost de Valk (AlthA)]

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)]

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

[David Kilzer (:ddkilzer)]

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

[Gérard Talbot (no longer involved)]

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

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.

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.

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

[Maros Ivanco]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Radar WebKit Bug Importer]

<rdar://problem/94402176>

[Tim Nguyen (:ntim)]

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