Closed
Bug 135236
Opened 22 years ago
Closed 14 years ago
Cell borders do not scroll in scrolling tbody with border-collapse:collapse
Categories
(Core :: Layout: Tables, defect, P2)
Tracking
()
RESOLVED
INVALID
Future
People
(Reporter: bugzilla, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: testcase)
Attachments
(1 file, 2 obsolete files)
3.44 KB,
text/html
|
Details |
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•22 years ago
|
||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Future
Comment 3•22 years ago
|
||
the testcase crashes for me on Linux. filed bug 149909
Comment 4•22 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.
*** Bug 189583 has been marked as a duplicate of this bug. ***
Comment 6•21 years ago
|
||
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•21 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•21 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•21 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.
Comment 11•21 years ago
|
||
> 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•21 years ago
|
||
*** Bug 192080 has been marked as a duplicate of this bug. ***
Comment 13•21 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
QA Contact: amar → madhur
Target Milestone: Future → ---
Updated•21 years ago
|
Target Milestone: --- → Future
Comment 14•20 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.
Comment 15•20 years ago
|
||
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•20 years ago
|
Assignee: minghong → nobody
QA Contact: madhur → core.layout.tables
Comment 16•20 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•19 years ago
|
||
*** Bug 295859 has been marked as a duplicate of this bug. ***
Comment 18•19 years ago
|
||
*** Bug 302408 has been marked as a duplicate of this bug. ***
Comment 19•18 years ago
|
||
*** Bug 355374 has been marked as a duplicate of this bug. ***
Comment 21•16 years ago
|
||
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•16 years ago
|
||
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?]
Comment 24•16 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.)
Comment 25•16 years ago
|
||
(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•16 years ago
|
||
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-
Comment 28•16 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•15 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!
Comment 32•15 years ago
|
||
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•15 years ago
|
||
Frederic, please see testcases at the "Attachment" section. Bug 498720 is clearly a duplicate.
Keywords: qawanted
Whiteboard: [reproducible on ppc?]
Comment 34•15 years ago
|
||
a little fix to the old testcase
Attachment #77504 -
Attachment is obsolete: true
Attachment #328223 -
Attachment is obsolete: true
Comment 35•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
this behavior will change if the scrolling is disabled due to bug 28800
Depends on: 28800
Updated•15 years ago
|
See Also: → https://launchpad.net/bugs/235006
(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
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•