Last Comment Bug 76497 - setting CSS property visibility: collapse on COL element doesn't collapse the column (<col>, <colgroup>, table, style, visibility, collapsed)
: setting CSS property visibility: collapse on COL element doesn't collapse the...
Visit bug 370353
: css2, testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
: P3 normal with 2 votes (vote)
: Future
Assigned To: layout.tables
: Madhur Bhatia
Depends on: 77019
  Show dependency treegraph
Reported: 2001-04-18 08:47 PDT by Martin Honnen
Modified: 2007-02-13 22:57 PST (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

test case/bug demo (clicking the button toggles the first columns visibility property but the table display is not changed) (720 bytes, text/html)
2001-04-18 08:49 PDT, Martin Honnen
no flags Details
testcase using HTML 4.01 strict (554 bytes, text/html)
2001-04-18 09:47 PDT, Boris Zbarsky [:bz]
no flags Details

Description Martin Honnen 2001-04-18 08:47:18 PDT
Accoding to the CSS 2 docs you should be able to collapse a table column by 
  visibility: collapse
on the COL element. I don't get that effect however with Mozilla.

<title>col test</title>
<input type="button" value="toggle column visibility"
       onclick="with (document.getElementById('aCol').style)
                 if (visibility == '')
                   visibility = 'collapse';
                   visibility = '';"
<table border="1">
<col id="aCol"
     style="background-color: blue;" 
     onmouseover="alert(event.type + ' for ' +;"
<col style="background-color: red;">
<a href=""></a>
Comment 1 Martin Honnen 2001-04-18 08:49:04 PDT
Created attachment 31308 [details]
test case/bug demo (clicking the button toggles the first columns visibility property but the table display is not changed)
Comment 2 Boris Zbarsky [:bz] 2001-04-18 09:45:35 PDT
It actually looks like visibility:collapse just has no effect on <col> elements
(even if set with an inline style attribute).  Attaching testcase.

Seeing this on linux build 2001-04-17-08
Comment 3 Boris Zbarsky [:bz] 2001-04-18 09:47:55 PDT
Created attachment 31311 [details]
testcase using HTML 4.01 strict
Comment 4 Johnny Stenback (:jst, 2001-04-18 10:56:19 PDT
Table layout problem, over to karnaze.
Comment 5 HJ 2001-04-18 10:57:51 PDT
And 'hidden' doesn't work, it only removes the background-color!
Comment 6 Fabian Guisset 2001-04-18 11:44:56 PDT
the border-collapsing code is currently disabled. Please see bug 41262
Comment 7 Boris Zbarsky [:bz] 2001-04-18 12:08:41 PDT
This bug is about column-collapsing, not border-collapsing.  Not the same thing.
Comment 8 karnaze (gone) 2001-04-18 13:02:03 PDT
Moving to m0.1.0.1
Comment 9 Bernd 2001-04-22 00:46:58 PDT
Is this a dupe of bug 32199?
Comment 10 Boris Zbarsky [:bz] 2001-04-22 12:15:02 PDT
No.  This is about elements with display:table-column, not about elements with
display:block or display:inline as bug 32199 is.  The behavior of
visibility:collapse is very different for things that have display:table-column
Comment 11 Don Eitner 2002-05-11 02:08:14 PDT
This issue is similar to bug 77019 (which is about collapsing a table's row
rather than column).  I have found some cases where both rows and columns do and
do not behave correctly in Mozilla 1.0.0+ nightly builds (I am using build
2002051008 for OS/2).

Note the test in the Debug menu, Viewer Demos sub-menu, #4 Simple Tables.  The
first two examples of row and column collapsing can be extracted (copy and paste
from the page source to a new page) and they display collapsed rows and
collapsed columns as expected (see
which has been validated as HTML 4.01 by the w3c).

But then if we remove the third and fourth tables from that (simply deleting
those tables from the HTML code and leaving absolutely everything else in the
file intact) the first example of collapsed rows and collapsed columns fails
(see which has also been validated as
HTML 4.01 by the w3c).

Both pages are valid HTML and use exactly the same code for the first and second
tables.  The only difference is that the second test page above has had the
third and fourth tables deleted.  This simple act causes table 2 to display
incorrectly in test4a.html where it worked correctly in test4.html.  Same code
but different display even in the same browser version.  And this was the code
taken from the Mozilla debug tests which are included with the browser binaries.
Comment 12 evan 2002-08-28 16:27:12 PDT
In 1.1 final for Linux, columns are hidden but not collapsed.  Also, reflowing
the page seems to make the column borders (but not content!) reappear.
Comment 13 karnaze (gone) 2003-03-31 11:24:05 PST
mass reassign to default owner
Comment 14 Hixie (not reading bugmail) 2003-11-15 04:49:44 PST
Comment 15 Vilmantas Baranauskas 2004-03-04 00:59:19 PST
"display: none" have no effect on "<col>" either. Shouldn't this bug be of hire
priority since (a) it should work according to CSS and (b) it works correctly on IE.
Comment 16 Bernd 2004-03-04 01:51:08 PST
no it should not have higher priority as there is already a patch in bug 77019
Comment 17 Bernd 2004-04-29 14:08:28 PDT
fixed by checkin for bug 77019
Comment 18 Gérard Talbot 2007-02-13 21:36:17 PST
Comment 19 Gérard Talbot 2007-02-13 21:38:37 PST

visibility: collapse on <col> and <colgroup> in border-collapse: separate model stopped working on the trunk for now quite some time (say, ~=6 weeks). In other words, test #5 (<col> visibility with border-collapse: separate) and test #7 (<colgroup> visibility with border-collapse: separate) taken from
attachment 147933 [details] 

were working before (say, ~=6 weeks; after reflow branch; at the time when table caption became as wide as document, not as wide as table). Now, they don't.

Same thing with the demo page

So, should I create a new bugfile or reopen this one?

Thank you for your understanding here,

Comment 20 Bernd 2007-02-13 22:00:47 PST
>So, should I create a new bugfile or reopen this one?

As this is not a flaw in the patch, the patch did what it was supposed to do please open a new bug. Minimized test cases are always welcome.

It would be cool to verify that it did change with the reflow branch landing.
Comment 21 Gérard Talbot 2007-02-13 22:57:54 PST
> please open a new bug.
For fans of this bug, visit bug 370353

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