Problems with 'overflow: scroll' on tbody

Created an attachment (id=77504)
Testcase showing bug

 Adding testcase Keyword.

the testcase crashes for me on Linux. filed bug 149909

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.

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

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.

"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.

> 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 :-).

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.

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.

> 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...

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

mass reassign to default owner

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.

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.

(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...

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

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

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

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

Created an attachment (id=328223)
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

Does this bug happen only on Windows or also with other OSes?

Requesting blocking or wanted flags for Fx 3.1

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

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

(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).

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.

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

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.

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!

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

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

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

Frederic, please see testcases at the "Attachment" section. Bug 498720 is clearly a duplicate.

Created an attachment (id=383730)
Minimal Testcase #3 (from Bug 424585)

a little fix to the old testcase

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

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

this behavior will change if the scrolling is disabled due to bug 28800

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

(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?

I think INVALID.