135236 - Cell borders do not scroll in scrolling tbody with border-collapse:collapse

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect, P2)

Description

[Jason Johnston]

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]

Attachment: Testcase showing bug

Comment 2

[Amarendra Hanumanula]

 Adding testcase Keyword.

Comment 3

[Andrew Schultz]

the testcase crashes for me on Linux.  filed bug 149909

Comment 4

[Kevin Jacobs]

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]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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]

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

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

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]

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 [:bzbarsky]]

> 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 [:bzbarsky]]

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

Comment 13

[karnaze (gone)]

mass reassign to default owner

Comment 14

[Ng Ming Hong]

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 [:bzbarsky]]

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]

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

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

Comment 18

[Bernd]

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

Comment 19

[Bernd]

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

Comment 21

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

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

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

Requesting blocking or wanted flags for Fx 3.1

Comment 24

[Jan Moesen]

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

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

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 28

[Florent Guiliani]

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]

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 32

[[e-mail]]

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

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

Comment 34

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Attachment: Minimal Testcase #3 (from Bug 424585)

a little fix to the old testcase

Comment 35

[[e-mail]]

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

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]

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

Comment 39

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

I think INVALID.