It appears that in the 12/23/98 build the colgroups are not working properly. Meaning that the columns etc. are not centering. Look at example 11.5 in the viewer and compare to the Image the w3 presents as an example of how it should look.
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
The problem is empty cells are requesting their default size rather than expanding to the size they are given. Table cells contain body frames to hold the cell content. Empty body frames used to expand to fill the available space automatically. This in turn would set the size of the cell properly. Now the cell frame forces the issue, resizing itself to fill the available space.
platforms tested: winnt 4.0 : build 99020820 macos 8.51: build 99020914 redhat 5.2: build 99020914 problem: i looked at the old url and created a testcase for it on wetnap. since i am new to this bug, i need some clarification. the summary above still holds true: seamonkey does not render the table properly. only the first row in the table is laid out. the rest never appear. This is the only part that renders (in ascii, but you get the picture) CODE-PAGE SUPPORT IN MICROSOFT WINDOWS =============================================================================== Code-Page | Name | ACP OEMCP | Windows Windows Windows ID | | | NT 3.1 NT 3.51 95 ------------------------------------------------------------------------------- expected behavior: the table should lay out like the one illustrated at http://www.w3.org/TR/REC-html40/images/table3.gif . there are several missing rows (about 15) action: if this is the wrong forum, i will open a new bug against this url. otherwise, (if i get no feed back) i will reopen this bug, clear the resolution, and update the OS/Platform to All/All old url: http://www.w3.org/TR/REC-html40/struct/tables.html#edef-TABLE new url: http://wetnap.mcom.com/seamonkey/bugs/bug2068.html
well, silence == consent. i'm reopening this bug. it still only lays out the very top of the table, as of RH52-i386 99021213 NT40-sp4 99021214 MacOS851 99021213
Whiteboard: the behavior has changed. will write a new testcase tonight.
BUILD march 24 1999 2pm -- WinNt4.0 march 24 1999 8am -- RedHat5.2
set target milestone.
Target Milestone: M5
changed misc bugs to M6
OS: Windows 95 → All
Whiteboard: the behavior has changed. will write a new testcase tonight. → 04-09-99 added
how close to the gif (http://www.w3.org/TR/REC-html40/images/table3.gif) do we plan to make our tables look? differences between the recommendation and what seamonkey (as of 1999-04-09-08ish) are as follows: 1. we draw borders around each cell. they have borders around each colgroup. 2. we draw some padding between each border. their adjacent borders have no padding. 3. we do not distinguish between different HBODY elements. they delineate with a horizontal border. 4. we do not identify colgroups with borders. this makes the logical grouping of the three OS columns in the fourth colgroup non-evident. i understand that theirs is just a recommendation and we have backwards compatibility to consider, but i do believe multiple HBODYs should be visibly separate and colgroups should also be apparent. so what is the plan?
setting my table bugs to M9
post beta, low priority table collapsing borders bugs
mass move to m14.
Moving to M16.
Target Milestone: M14 → M16
Wow. This bug is old. How come I never came across it before??? :-/ chrisd: Could you attach the testcase to this bug? Currently it's netscape- intranet-only. Cheers. David: It's probably another rules/frames resolution thing. Thought you might want to know this bug exists, since I think you were looking at the code a few weeks ago.
The best test case is at the bottom of http://www.w3.org/TR/html401/struct/tables.html Copy the html on example 11.5 and view that. Good you can see many places where it misses
*** Bug 34107 has been marked as a duplicate of this bug. ***
ok this is old, it needs to be fixed. :) We just need http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7539 to look like http://www.w3.org/TR/html401/images/table3.gif
Severity: normal → critical
Moving to M17. border-collapse and/or rules will be handled then.
Target Milestone: M16 → M17
Nominating for Mozilla 0.9 when hopefully the border collapse rules will be fixed as well.
Whiteboard: 04-09-99 added → 04-09-99 added, related to border collapse.
How can a critical bug be P4? We need a new milestone here too.
Target Milestone: M17 → ---
moving to m1.0
Target Milestone: --- → mozilla1.0
QA contact update
QA Contact: chrisd → amar
Whiteboard: 04-09-99 added, related to border collapse. → [awd:tbl] 04-09-99 added, related to border collapse.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Any motion on this bug? It's only ~4 years old :)
fixed by meta bug 41262
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago → 16 years ago
Resolution: --- → FIXED
Works fine accoring to the specifications. Marking verified. Build ID : 2002030403
Status: RESOLVED → VERIFIED
I'm new to this bug stuff, but this is NOT fixed for build 2002041711 aka 1.0 release candidate 1.
<colgroup align=..> not working on things inside the colgroup is another bug (can't recall the bug number). Before bug 41262 was fixed, none of the rules showed up. I'm leaving this open to deal with the problem where the cols inside the colgroups with span > 1 are getting rules (but that may be another bug as well). Marking nsbeta1-, since the only reason that it was marked nsbeta1+ was because it was thought to be fixed with bug 41262.
Severity: critical → normal
Status: VERIFIED → REOPENED
Priority: P4 → P3
Resolution: FIXED → ---
Target Milestone: mozilla0.9.9 → Future
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [awd:tbl] 04-09-99 added, related to border collapse. → [awd:tbl][HTML4-18.104.22.168] 04-09-99 added, related to border collapse.
The only remaining problem is the alignment which is bug 915. Karnaze said in comment 30: I'm leaving this open to deal with the problem where the cols inside the colgroups with span > 1 are getting rules (but that may be another bug as well). This is bug 127798, which is worksforme. *** This bug has been marked as a duplicate of 127798 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → DUPLICATE
Wait a minute! You just marked this as a duplicate of a resolved bug, yet it still depends on a different unresolved bug. Isn't this inconsistent? I think it would make more sense to mark it as a duplicate of 915 because that is the only remaining unresolved bug that this bug depends on.
Verified dupe Sorry for the spam
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.