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.

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

clearing resolution

BUILD march 24 1999 2pm -- WinNt4.0 march 24 1999 8am -- RedHat5.2

set target milestone.

changed misc bugs to M6

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.

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

I think this bug would be fixed by a plan similar to the one I described in bug 965 (which assumed that bug 9191 was fixed).

Moving to M17. border-collapse and/or rules will be handled then.

Adding dependency on bug 41262.

Nominating for Mozilla 0.9 when hopefully the border collapse rules will be fixed as well.

How can a critical bug be P4? We need a new milestone here too.

moving to m1.0

QA contact update

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)

Any motion on this bug? It's only ~4 years old :)

Marking nsbeta1+

fixed by meta bug 41262

Works fine accoring to the specifications. Marking verified. Build ID : 2002030403

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.

The first problem I mentioned in comment #30 is bug 915.

nsbeta1-

Adding 915 and 127798 to dependency list

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

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