29055 - VALIGN not working whith COLGROUP

Status: RESOLVED DUPLICATE of bug 915

(Core :: Layout: Tables, defect, P3)

Description

[u11984]

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

Comment 1

[u11984]

Attachment: Test case for the bug

Comment 2

[Richard Zach]

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

Comment 3

[u11984]

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

Comment 4

[karnaze (gone)]

Mark, this is related to bug 915.

Comment 5

[u11984]

Attachment: Sorry, I meant to send this...

Comment 6

[Chris Petersen]

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

Comment 7

[leger]

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

Comment 8

[leger]

Mailed to rickg to mark PDT+ or PDT-.

Comment 9

[rickg]

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.

Comment 10

[Marc Attinasi]

COL / COLGROUP moving to M16

Comment 11

[Christine Hoffman]

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

Comment 12

[Marc Attinasi]

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. 

Comment 13

[Marc Attinasi]

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).

Comment 14

[leger]

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.

Comment 15

[Marc Attinasi]

This should be de-nominated beta2: we decided previously that this was to be 
addressed after beta2 (see [e-mail] 2000-05-03 12:33)

Comment 16

[Gervase Markham [:gerv]]

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

Comment 17

[karnaze (gone)]

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

Comment 18

[ekrock's old account (dead)]

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.

Comment 19

[Hixie (not reading bugmail)]

ekrock: see my comment in bug 915.

Comment 20

[karnaze (gone)]

Reassigning to glazman and moving to m1.0.

Comment 21

[Alan Eliasen]

Attachment: Test case taken from HTML 4.01 specification

Comment 22

[Asa Dotzler [:asa]]

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)

Comment 23

[Alan Eliasen]

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.

Comment 24

[Mark J. Reed]

This applies to horizontal alignment (ALIGN) as well.

Comment 25

[Jungshik Shin]

> "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... 

Comment 26

[David E. Ross]

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).  

Comment 27

[:aceman]

This is a duplicate of bug 915 ...

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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