The default bug view has changed. See this FAQ.

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

RESOLVED INVALID

Status

()

Core
Layout: Tables
P2
normal
RESOLVED INVALID
15 years ago
3 years ago

People

(Reporter: Jason Johnston, Unassigned)

Tracking

(Depends on: 1 bug, {testcase})

Trunk
Future
x86
All
testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -
wanted1.9.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

15 years ago
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>.
(Reporter)

Comment 1

15 years ago
Created attachment 77504 [details]
Testcase showing bug

Updated

15 years ago
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Future

Comment 2

15 years ago
 Adding testcase Keyword.
Keywords: testcase

Comment 3

15 years ago
the testcase crashes for me on Linux.  filed bug 149909

Comment 4

15 years ago
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

14 years ago
*** 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.

Comment 7

14 years ago
"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 :-).

Comment 9

14 years ago
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.
(Reporter)

Comment 10

14 years ago
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. ***

Comment 13

14 years ago
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
QA Contact: amar → madhur
Target Milestone: Future → ---

Updated

14 years ago
Target Milestone: --- → Future

Updated

13 years ago
Depends on: 203686

Comment 14

13 years ago
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.
Assignee: core.layout.tables → minghong

Updated

13 years ago
Assignee: minghong → nobody
QA Contact: madhur → core.layout.tables

Comment 16

13 years ago
(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

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

Comment 18

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

Comment 19

11 years ago
*** Bug 355374 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 424585
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
Does this bug happen only on Windows or also with other OSes?

Requesting blocking or wanted flags for Fx 3.1
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Keywords: qawanted
Whiteboard: [reproducible on Linux and Mac?]
Duplicate of this bug: 224613

Comment 24

9 years ago
> 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.
OS: Windows 2000 → All
Whiteboard: [reproducible on Linux and Mac?] → [reproducible on ppc?]
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1?
Flags: blocking1.9.1-

Updated

9 years ago
Duplicate of this bug: 456789

Comment 28

9 years ago
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

8 years ago
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!
Duplicate of this bug: 443818

Updated

8 years ago
Duplicate of this bug: 498720
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.
Keywords: qawanted
Whiteboard: [reproducible on ppc?]
Created attachment 383730 [details]
Minimal Testcase #3 (from Bug 424585)

a little fix to the old testcase
Attachment #77504 - Attachment is obsolete: true
Attachment #328223 - Attachment is obsolete: true
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

Comment 37

8 years ago
this behavior will change if the scrolling is disabled due to  bug 28800
Depends on: 28800
Duplicate of this bug: 532374

Updated

7 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.