Last Comment Bug 135236 - Cell borders do not scroll in scrolling tbody with border-collapse:collapse
: Cell borders do not scroll in scrolling tbody with border-collapse:collapse
Status: RESOLVED INVALID
: testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: x86 All
: P2 normal with 12 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 189583 192080 224613 295859 302408 355374 424585 443818 456789 498720 532374 (view as bug list)
Depends on: 203686 28800
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-03 12:26 PST by Jason Johnston
Modified: 2014-04-26 03:11 PDT (History)
35 users (show)
roc: blocking1.9.1-
roc: wanted1.9.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase showing bug (3.35 KB, text/html)
2002-04-03 12:27 PST, Jason Johnston
no flags Details
Minimal Testcase #2 (from Bug 424585) (3.45 KB, text/html)
2008-07-05 11:40 PDT, Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)
no flags Details
Minimal Testcase #3 (from Bug 424585) (3.44 KB, text/html)
2009-06-17 09:05 PDT, Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)
no flags Details

Description Jason Johnston 2002-04-03 12:26:46 PST
See attached testcase.  Seen using build 2002040303 on Win2K.

When scrolling portions of a table using overflow:auto (<tbody> for instance),
the borders for cells within that section appear to be anchored separately from
their cells, so they don't scroll with the cell content.  

In addition, the borders extend below of the bounds of the <tbody>.
Comment 1 Jason Johnston 2002-04-03 12:27:36 PST
Created attachment 77504 [details]
Testcase showing bug
Comment 2 Amarendra Hanumanula 2002-05-03 17:00:25 PDT
 Adding testcase Keyword.
Comment 3 Andrew Schultz 2002-06-07 05:02:36 PDT
the testcase crashes for me on Linux.  filed bug 149909
Comment 4 Kevin Jacobs 2002-12-10 07:38:52 PST
Verified that this bug still occurs in the 1.2.1 release.
Our table renderer is tuned for border-collapse: collapse;,
so it would be nice to get this one fixed.
Comment 5 Bernd 2003-01-18 06:10:08 PST
*** Bug 189583 has been marked as a duplicate of this bug. ***
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2003-02-03 20:56:21 PST
This is an interesting one... in border-collapse:collapse mode, the borders
belong to the table, not the cells.  It's not clear what the scrolling behavior
should be.
Comment 7 Kevin Jacobs 2003-02-04 05:46:31 PST
"in border-collapse:collapse mode, the borders belong to the table, not the cells. 
It's not clear what the scrolling behavior should be."?!?  

I'll beg to differ on this one -- it is the tbody block that is scrolling, not 
the cells.  Thus, I think that the correct behavior is quite clear.
Besides, ask any user -- they'll tell you without equivocation what behavior
_they_ expect (and demand!), even if the standards are unclear.
Comment 8 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-02-04 05:58:01 PST
> Besides, ask any user -- they'll tell you without equivocation what behavior
> _they_ expect

That would be helpful except that typically, each user expects a *different*
behavior :-).
Comment 9 Kevin Jacobs 2003-02-04 06:05:02 PST
In many cases I'd agree that users tend to expect strange and non-intuitive
things.  However, in this case I believe it is fairly clear cut.  We
(my company) is holding back from releasing versions of our products
that support Mozilla until this bug and the related sizing problems
with scrolling tbodies are fixed.

Just our 2cents, but those pennies do add up.
Comment 10 Jason Johnston 2003-02-04 08:18:34 PST
Boris, could you please elaborate on what you mean by "the borders
belong to the table, not the cells"?  Do you mean this is how it is currently
treated in Gecko's architecture, or is there some wording in the CSS spec to
that effect (I couldn't find any)?  In either case it's perhaps a bit
counterintuitive because the borders are explicitly set on the *cells* in the
CSS ( td {border:1px dotted blue;} ), not any other part of the table.

I can see though that this is more complicated than it appears at first, and
brings up issues that may not have been thought of when the spec was defined. 
For instance, the border-collapse:collapse scheme says that borders that meet
are combined in a very clearly defined way.  But when you scroll the <tbody>,
all of a sudden you are separating certain borders (i.e. those that meet between
the <thead>/<tfoot> and <tbody>).  Or actually you are creating a situation in
which borders may be meeting at some times and not meeting at others.  Take the
top of a <tbody> with overflow:auto where it meets the bottom of the <thead>:
when scrolled to the top the borders meet (and you would expect the
collapsing-borders rules to apply) but when scrolled down a way those borders no
longer meet and are effectively separated.  

While it may seem obvious from the viewpoint of a web developer who wants it to
"just work", these kinds of details that implementors have to deal with are not
nearly so obvious.

Perhaps this should be brought up to the CSS WG.
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2003-02-04 11:18:02 PST
> Do you mean this is how it is currently treated in Gecko's architecture

Yes.

> is there some wording in the CSS spec

Not explicitly, but the spec _does_ say that the borders do not quite belong to
the individual cells (as in, the border between two cells depends on both of
their borders in a complicated way).

And of course there's the problem with thead/tfoot that you point out...

> Perhaps this should be brought up to the CSS WG.

Which?  The fact that the border-collapse model is pretty incompatible with
everything else in CSS2?  I think glazou is bringing that up in the WG per our
conversation last night...
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2003-02-05 20:04:44 PST
*** Bug 192080 has been marked as a duplicate of this bug. ***
Comment 13 karnaze (gone) 2003-03-31 10:40:28 PST
mass reassign to default owner
Comment 14 Ng Ming Hong 2004-06-10 00:38:59 PDT
When will this bug be fixed? It was filed 2 years ago.
I'd like to scroll my tbody and single line table looks nicer. Unless there is
another method to create single line table without using border-collapse, I
would like to see this bug fixed.
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2004-06-10 10:04:08 PDT
This bug will be fixed when someone has time and desire to fix it (and when the
CSS spec becomes somewhat clear as to what the "right" behavior is).

Thank you for volunteering.
Comment 16 artemy 2004-11-05 18:48:48 PST
(In reply to comment #14)
> When will this bug be fixed? It was filed 2 years ago.
> I'd like to scroll my tbody and single line table looks nicer. Unless there is
> another method to create single line table without using border-collapse, I
> would like to see this bug fixed.

you can achieve a 1-pixel table-cell border through non-CSS means (or partially
CSS means).  set the background color of the table to the desired border color,
and the TD background the desired background.  use border=0 and cellspacing=1
for attributes.  hackish, but it works.
for example:
<STYLE>
TABLE { background: black; }
TD { background: white; }
</STYLE>
<TABLE BORDER=0 CELLSPACING=1>
<TR><TD> ... etc etc ... </TD></TR>
</TABLE>

----------
its worth a shot, although unfortunately, there are massive other issues with
scrolling TBODYs (cells dont align, size of table shifts around as you're
scrolling, etc.)  hopefully somebody will take a peek at this bug in the near
future...
Comment 17 Bernd 2005-05-29 11:17:00 PDT
*** Bug 295859 has been marked as a duplicate of this bug. ***
Comment 18 Bernd 2005-07-27 21:32:07 PDT
*** Bug 302408 has been marked as a duplicate of this bug. ***
Comment 19 Bernd 2006-10-04 12:41:39 PDT
*** Bug 355374 has been marked as a duplicate of this bug. ***
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2008-07-05 10:36:49 PDT
*** Bug 424585 has been marked as a duplicate of this bug. ***
Comment 21 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2008-07-05 11:40:48 PDT
Created attachment 328223 [details]
Minimal Testcase #2 (from Bug 424585)

In this testcase no col elements are used, and the bug make worse. Also background is affected. See the testcase for a better description.

Related bugs: bug 317137, bug 423823, bug 439639
Comment 22 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2008-07-05 11:49:10 PDT
Does this bug happen only on Windows or also with other OSes?

Requesting blocking or wanted flags for Fx 3.1
Comment 23 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2008-07-05 11:49:44 PDT
*** Bug 224613 has been marked as a duplicate of this bug. ***
Comment 24 Jan Moesen 2008-07-05 13:02:43 PDT
> Does this bug happen only on Windows or also with other OSes?
Also on Mac.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1pre) Gecko/2008061904 Firefox/3.0pre

(Wow, out of date, anyone? But there have not been any check-ins, anyway.)
Comment 25 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2008-07-05 13:24:18 PDT
(In reply to comment #24)
> rv:1.9.0.1pre

It's not the latest trunk, can you retest on it?

> Wow, out of date, anyone?

Probably this bug will not be fixed until W3C will define clearly in CSS3 specs for table layout (read comments above).
Comment 26 Tony Mechelynck [:tonymec] 2008-07-05 16:57:11 PDT
Duplicate bugs 224613, 355374 are on Linux, comment #24 on Intel Mac => PC/All
If you can reproduce on PPC mac, change Hardware to All.
Comment 27 philippe (part-time) 2008-09-24 19:45:23 PDT
*** Bug 456789 has been marked as a duplicate of this bug. ***
Comment 28 Florent Guiliani 2008-10-23 04:20:44 PDT
When I look at the test cases, it's obvious that:
 - border shouldn't outfit table
 - border should scroll with cells
...despite any standard approximation.
Comment 29 Ganesh 2009-01-25 08:05:01 PST
Came across this bug when trying to implement a scrolling table. Used the cellspacing solution of artemy (see above), but with border-spacing in css instead, so I could use a user agent detection. Works great!
Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2009-02-13 07:19:08 PST
*** Bug 443818 has been marked as a duplicate of this bug. ***
Comment 31 philippe (part-time) 2009-06-16 19:20:30 PDT
*** Bug 498720 has been marked as a duplicate of this bug. ***
Comment 32 frederic.fanchamps@skynet.be 2009-06-17 03:39:12 PDT
I'm a developper and have reported 498720 marked as duplicate. I don't know if it is exactly a duplicate: I don't ask for collapse option (or are they default?).
I just see that "rules" are displayed as if no height at all is defined for tbody, and that they don't scroll at all with the tbody.
Answer in 2003 was: "It's not clear what the scrolling behavior
should be."
There are 2 problems:
-A- rules are displayed as if no height at all is defined for tbody
-B- rules don't scroll with the tbody
Excuse me but the correct behavior IS well clear for both, nothing to do with strange user requirements.
I can understand that firefox is developped on a volunteer basis and that the bug is difficult to correct (however 7 years after first report and from the marketing point of view in a totally rewritten version)
But I can not understand that the reason is <<It's not clear what the scrolling behavior should be.>> even more for part -A- where no scrolling at all is involved.
I wanted to present firefox as a enterprise solution to replace some LotusNotes and SAS screens but I am very disappointed.
Fred
Comment 33 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2009-06-17 09:02:54 PDT
Frederic, please see testcases at the "Attachment" section. Bug 498720 is clearly a duplicate.
Comment 34 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2009-06-17 09:05:33 PDT
Created attachment 383730 [details]
Minimal Testcase #3 (from Bug 424585)

a little fix to the old testcase
Comment 35 frederic.fanchamps@skynet.be 2009-06-17 09:37:52 PDT
Ok Lucas thanks for the info.
I thought the rendering engine was completely rewritten so I am surprised by the fact that a bug of 2002 still exist as it was.
Or was only part of the engine rewritten?
Frederic
Comment 36 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2009-06-18 02:15:39 PDT
The problem is CSS specs are not very clear for this behaviour. Firefox can add a workaround, but for what I understood this bug is not so popular and serious. See Comment #11
Comment 37 Bernd 2009-07-18 04:31:36 PDT
this behavior will change if the scrolling is disabled due to  bug 28800
Comment 38 David Baron :dbaron: ⌚️UTC-7 2009-12-02 13:53:19 PST
*** Bug 532374 has been marked as a duplicate of this bug. ***
Comment 39 David Baron :dbaron: ⌚️UTC-7 2010-01-25 13:45:40 PST
(In reply to comment #37)
> this behavior will change if the scrolling is disabled due to  bug 28800

Should we mark this as worksforme or fixed or invalid now?
Comment 40 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-01-25 15:27:57 PST
I think INVALID.

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