As shown in the test case setting the value of the VALIGN attribute to "top" or "bottom" doesn't yield the desired result.

If I see this right, COLGROUP is not working at all: width and halign specifications are also ignored.

I'm running M13 on Windows NT 4.0 US SP6 with IE 5.01.

Mark, this is related to bug 915.

Since this attribute is completely failing, adding beta1 to keywords.

rickg, checking on this one for PDT+ or -.

Mailed to rickg to mark PDT+ or PDT-.

Marking PDT-, due to two factors: 1) it's a less common technique in HTML; 2) the risk of the potential change is unknown. Karnaze: if either assumption is wrong, please resubmit for beta1.

COL / COLGROUP moving to M16

PDT- removed; assumed it was from beta1. Please re-review for nsbeta2.

COLGROUP style support is looking like it won't make it into Beta2 - it requires lots of involved changes in both Style and in Table code and we probably won't have the manpower to get these changes done in time.

The problem is that COL and COLGROUP support requires coordination between tables and style; Karnaze and I have spent a bit of time discussing the possible approaches and they are all either involved or incomplete. The root of the problem is that COL and COLGROUP do not follow the actual element heirarchy and so style selectors using COL and COLGROUP require calling into the table code during resolution to determine which cells are actually in which column. Also, the DOM can change the column of a cell by insertion or removal of cells and then we need to determine which cells are affected and re-resolve them. This complexity is compounded by the fact that the style system has no good generic mechanism to call into the table code at style resolution time to make the determinations required, and also Chris K. is busy with much more important table issues (like collapsed borders). For these reasons we were hoping to get this off of the nsbeta2 radar (along with bug 915 which is related).

Ok..giving a [nsbeta-] gerarodk, erick, and attinasi all agree that this will not make PR2. Thus, wait until follow up Netscape 6 product. However, will put on helpwanted keyword radar in case the net community can help us.

This should be de-nominated beta2: we decided previously that this was to be addressed after beta2 (see leger@netscape.com 2000-05-03 12:33)

Nominating rtm so that we realise that this is another one we said we'd fix but have ignored for the past _four_ _months_! :-) I fully expect it to be rtm-'ed... Gerv

Gervase, I'm afraid you're right. Marking rtm-.

Nom. nsbeta1. If possible, we'd like to get COLGROUPs working for nsbeta1 and embedded applications to enable a robust COLGROUP-enabled platform for new content going forward.

ekrock: see my comment in bug 915.

Reassigning to glazman and moving to m1.0.

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)

I just visited one of my own pages ( http://futureboy.homeip.net/bjexec/hodds.exe ) and noticed that Mozilla has recently started to render COLGROUP's 'hsides' and 'vsides' rules correctly. The "Testcase from HTML 4.01 specification" attachment that I submitted above works correctly now also. There has obviously been some work done by someone at least tangentially related to this problem. In fact, my problems are finally solved. Thanks to whoever worked on this.

This applies to horizontal alignment (ALIGN) as well.

> "Testcase from HTML 4.01 specification" attachment that I submitted above > works correctly now also. Really? It doesn't for me(2003-05-xx). I'm afraid it won't until it's decided as to what to do with CSS vs HTML.. linear inheritance vs 2-d nature of table...

This problem can be seen in the rather small [http://www.rossde.com/op_bulbrd.html]. At about half-way down the page is a two-column, three-row table (number of rows subject to change). This problem is visible with Mozilla 1.4RC1 (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529).

This is a duplicate of bug 915 ...

*** This bug has been marked as a duplicate of 915 ***