Closed Bug 58887 Opened 24 years ago Closed 23 years ago

classes and ids in colgroups and cols are ignored

Categories

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

defect

Tracking

()

VERIFIED INVALID
Future

People

(Reporter: st.n, Assigned: karnaze)

References

Details

(4 keywords, Whiteboard: [awd:tbl])

Attachments

(10 files)

Load the (soon) attached testcase into Mozilla. It shows a two by three table
where the right (third) column should have a green background, because the <col>
has an id attribute and there is a CSS entry setting the background color to
green for this id.

IE does this correctly, Mozilla build 2000110120 does not.
Attached file test case
added some keywords
class worked for me, but id is indeed broken. Weird.
Blocks: html4.01
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: classes and ids in colgroups and cols are ignored → ids in colgroups and cols are ignored
Attached file extended test case
    I have added a second test case. There are two tables now, the first one is
unchanged and the second one uses the class attribute instead of id. Both are
valid HTML 4.01 (http://validator.w3.org), and both should show a colored third
column.

    And there is a third issue: the second table should be at the right margin
of the window, not at the left, because of the CSS for the div tag. But maybe
this should be a different bug. :-(

    Unfortunately IE does all three things correctly, and as I would expect from
the HTML 4.01 and CSS 2 spec. Changing the summary back.
Summary: ids in colgroups and cols are ignored → classes and ids in colgroups and cols are ignored
I'm not sure this is a bug. The testcases work with a 'strict' doctype which 
will put the document into 'standard' mode. They fail in 'quirks' mode which I 
think is intended since Nav never rendered these .
    That second testcase works for me, too, at least the colors part. But I
don't understand why it shouldn't work with a transitional DTD. That's how
it is specified in the W3C spec for HTML 4.01, strict or transitional, and
the "old way" how Nav would do it is marked deprecated, so I wouldn't
normally want to use it any more.

    So why should ids and classes be only part of the strict DTD? I think
the transitional DTD should only support some old attributes in addition to
the new tags and attributes, but not support less. Or am I wrong here?

    But the second table is still left-aligned. It should be rendered at
the right side of the window because of the "div { text-align: right; }"
CSS code and the <div> around it. Or did I misunderstand the specs here?

    And still, IE does all that as I would expect. Don't we want to be
better than IE? :-/  Or tell me what IE is doing wrong here.
Pierre: can you comment on the 'quirk' v.s. 'standard' behavior regarding 
the color issue?
> But the second table is still left-aligned. It should be rendered at
> the right side of the window because of the "div { text-align: right; }"
> CSS code and the <div> around it. Or did I misunderstand the specs here?

You did. 'text-align' should only right-align the text. To right-align the whole
table, use 'margin-left: auto; margin-right: 0;'.
Do we know whether this is a bug?  If so, we should add a <= Moz1.0 nomination.
Nominating for Moz0.9
Keywords: mozilla0.9
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
nominate for 1.0. Will attach another test case, this one font based. Shows
class on <col> element being ignored. Document is validated as 4.0 transitional
Keywords: mozilla0.9mozilla1.0
That last test case is invalid (the <col> element is empty, so what should its
font apply to?).
Component: Style System → HTMLTables
QA Contact: ian → amar
No it isn't invalid.  What do you mean when you say that the COL element is
empty?  It has to be empty!
This bug is not dependent on whether the DOCTYPE is transitional or strict.  It
occurs in both cases!  I have attached a validated HTML 4.01 strict test case to
prove this.  The test case shows both style and class attributes effectively
being ignored on COL elements within tables.  It then goes on to illustrate that
the rules attribute is also ignored.  I have included this as I have actually
seen no evidence that Mozilla supports COL and COLGROUP elements at all, and
this serves to illustrate the point although it is admittedly a separate bug
(maybe bug 24113?).

This bug definitely needs fixing before Mozilla 1.0 as it is a standards
compliance issue.  As it is, Mozilla is not HTML 4 compliant.  Even if the bug
only occured with a strict DOCTYPE declaration it would still break standards
compliance as the W3 specs clearly state that COL and COLGROUP should work in
both strict and transitional HTML.

This is a serious issue which seems to be getting little priority at the moment.
 What can we do to change this?
Sorry, I forgot to mention my browser version.  I have checked my testcase
against Mozilla 0.9 build 2001051804 on Win98SE (Intel).  I've been using
Mozilla for some time now, and have never observed different results in any version.
Hixie - you moved this bug over to HTMLTables without reassigning to karnaze. Is 
that right?

Gerv
Gerv: yes, this is Pierre's bug IMHO. I might be wrong of course. However I
prefer to leave that decision up to Pierre.

max.spicer: font only affects the children of elements in CSS, and since columns
never have children, font on column elements in CSS have no effect. See  
   http://www.w3.org/TR/REC-CSS2/tables.html#q4
...which says that only 'border', 'background', 'width' and 'visibility' applies
to columns (and borders only in the collapsed border model, which we don't 
support anyway).
Ian Hickson: Apologies, the first (and only relevant) part of my testcase is 
indeed invalid.
Classes and ids both work in colgroups and cols right now, in both Quirks and
Standard layout mode (testing Win98 2001070708). Is that sufficient to mark this
bug fixed?
  classes and id with colgroups and cols works only in standard mode but does 
not work in Quirks mode... I tested this on win2000 and Build ID # 
2001-07-11-06-0.9.2... I dont think you can mark this bug as fixed if it works 
on win98..... I does not work on win2k
The problem is that you're testing for backgrounds. Backgrounds are disabled on 
columns in Quirks mode; the style is resolved properly--it just doesn't get 
painted. You can test for 'width' and verify that classes and ids are indeed 
supported for column elements.
Style support on row groups and columns is very, very, very, very, very, very
broken, regardless of strict or quirks mode. 

Row group problems: Border styles don't work at all. Background images work but
leave bits of background color showing at the left and right ends and some
crumbs between cells, too.

Column problems: Font, text, and border styles don't work at all. Background
images work but leave bits of background color showing at the top and bottom ends.

The sum total of these problems surpass any one of the single bugs filed on
them. The topic of style support on row groups and columns must be said to be
broken at this point, and requires some serious, dedicated, focused attention
before it can be taken seriously on this product.
Greg: Can you provide testcases, please?
What's more needed is a metabug, "Implement HTML and CSS Style Capability For
Row Groups, Columns, and Column Groups" to organize all the bugs on the subject.
I'll create one this afternoon.
Border styles only apply to row groups and column elements in the collapsed 
border model--which is currently disabled, as it "needs rework". See bug 41262.

Background problems are covered by bug 4510.

Font and text properties don't inherit through columns as the table cell is not 
a child of the column element.

If I'm understanding this bug correctly, it was opened for not resolving styles 
via class/id. That has nothing to do with whether the styles are implemented 
correctly or not, as the problem applies whether one uses classes, ids, tag 
names, or the style attribute.

amar@netscape.com -- Unless for some wild reason the Quirk width testcase 
doesn't work on a non-Win32 build, please mark this bug either fixed or invalid.
Keywords: qawanted
In fact, the bug should be reassigned to karnaze to mark it invalid or dup.
Chris, you can ignore the comments prior to [Hixie 2001-06-11 11:31].
Assignee: pierre → karnaze
For the record, this seems to apply to the style attribute as well.

I'm getting some very interesting results with these last two testcases.  

javascript:var x =
document.getElementsByTagName("colgroup")[0].getAttribute("style");alert(x)

returns "color: rgb(255,0,0); background-color: rgb(0,255,0);" for the col
testcase, "color: red; background-color: rgb(0,255,0);" for the colgroup testcase.

This means the DOM is at least correctly reading these attributes.

Based on that, I think I can create a JavaScript-based patch for this bug. 
There'd be a few steps.

Iterating through the child elements of each <tr>...</tr> tag, we could (a) grab
the local <td>...</td> or <th>...</th> styling, (b) apply the corresponding
colgroup or col styling on top of it, and (c) reapply the original <td>...</td>
or <th>...</th> styling on top of that.  Best I can come up with, given I don't
know C++.

Mr. Kolanek, did you ever file that meta bug?

I'm not that strong with JavaScript styling... I'll probably tinker around with
it after this weekend (finishing a book).
Take a look at the source for this one, via
view-source:http://bugzilla.mozilla.org/attachment.cgi?id=52324&action=view

Note the body onload event handler.  Something else to note:

-- When I applied the colgroup styling to the first td, it wiped out the styling
of the second td (which was inherited from the colgroup).  Hence the nextSibling
bit.

-- I know fully well this code does not correctly use DOM styling.  But it
works... if someone would care to help me do this correctly, I'd appreciate it.
This bug is fixable via JavaScript, without too much trouble.  The question is
will Mozilla.org accept a JavaScript patch, or will someone have to translate a
JS patch to C++?
Alex, you what you are attempting to fix is not a JS problem. It's coded into
C++. Also, it's not broken: styles do not inherit through columns because they
aren't supposed to. Moreover, that's not what this bug was filed for.

IMO, this bug is getting way too much attention for something which should have
been marked invalid months ago.
Whiteboard: [awd:tbl]
Temporarily moving to future until a milestone can be assigned. 
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Resolving INVALID, with permission from karnaze@netscape.com. Please verify.
(For reasoning, see comments 26 and 31.)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: mozilla1.0, qawanted
Resolution: --- → INVALID
 COL, COLGROUPS and border style have been recently reworked and checked in.
Marking verified form the above comments. 
Status: RESOLVED → VERIFIED
This bug should not be invalid.  From comment #31 which is the basis for making
this bug's status invalid: "Font and text properties don't inherit through
columns as the table cell is not a child of the column element."

I think this statement is wrong.

From the HTML4.01 spec 11.2.4:
"Column groups allow authors to create structural divisions within a table.
Authors may highlight this structure through style sheets or HTML attributes ..."
"The COL element allows authors to share attributes among several columns..."
And ID, CLASS, TITLE, STYLE are all valid attributes of <COL> and <COLGROUP>

From HTML4.01 spec 11.3.2:
"Inheritance of alignment specifications  ..."
"The order of precedence (from highest to lowest) for the attribute valign (as
well as the other inherited attributes lang, dir, and style) is the following:

   1. An attribute set on an element within a cell's data (e.g., P).
   2. An attribute set on a cell (TH and TD).
   3. An attribute set on a row or row grouping element (TR, THEAD, TFOOT, and
TBODY). When a cell is part of a multi-row span, the attribute value is
inherited from the cell definition at the beginning of the span.
   4. An attribute set on a column grouping element (COL and COLGROUP). When a
cell is part of a multi-column span, the attribute value is inherited from the
cell definition at the beginning of the span.
   5. An attribute set on the table (TABLE).
   6. The default attribute value."

So a style attribute can be inherited by a TD from a COL.

And from the CSS1 specification: ALL font properties, many text properties, and
the color property apply to ALL elements and are inherited.

Using the color property as an example, I will summarize:
The COL element can have a STYLE attribute applied directly or indirectly by a
CLASS attribute.  
The COLOR property can apply to the COL element by using the STYLE attribute or
by inheriting it.
The TD element can inherit the STYLE attribute containing the COLOR property
from the COL element.  Therefore the TD element can inherit the COLOR (and FONT)
property from a COL element.  And this is not an invalid bug.

> From comment #31 which is the basis for making this bug's status invalid:
> "Font and text properties don't inherit through columns as the table cell is
> not a child of the column element."

The third paragraph of comment 31 is the basis for making this bug's status 
invalid. What you quote here is in reply to a point made in comment 28 by Greg 
K. which has nothing to do with this bug.

> So a style attribute can be inherited by a TD from a COL.

It is my opinion that this part of the HTML4.01 spec is in error. However, if 
you feel that the value of the style attribute should indeed be inherited by the 
columns' cells, then file a new bug. It has nothing to do with whether id and 
class are recognized on <col> and <colgroup>, which is what this bug is about.

> And from the CSS1 specification: ALL font properties, many text properties,
> and the color property apply to ALL elements and are inherited.

In CSS, properties are inherited from an element's parent. <col> is an empty 
element; it has no children. It follows that <col> cannot be the parent of a 
table cell.

> The COL element can have a STYLE attribute applied directly or indirectly by a
> CLASS attribute.  

Incorrect. A <col> element can have style properties applied by selecting it 
with a class attribute selector. The value of the 'style' *attribute* is not 
affected by its 'class' attribute (unless you use scripting to pick out elements 
with that class and dynamically set the style attribute).

> The COLOR property can apply to the COL element by using the STYLE attribute
> or by inheriting it.

This is correct.

> The TD element can inherit the STYLE attribute containing the COLOR property
> from the COL element.

This is, IMO, debatable.

> Therefore the TD element can inherit the COLOR (and FONT) property from a COL
> element.

Not quite. You are mixing up the value of the 'style' attribute (which is a 
_string_) with the element's computed style (which is stored separately from the 
elements' markup information). Computed style comes from a variety of sources, 
including the value of an element's 'style' attribute. The value of the style 
attribute only comes from the DOM. Taken literally, HTML4.01 specifies that the 
value of the style attribute inherits from the column to the cell. However, this 
implies nothing about the inheritance of CSS properties.

Consider this example:
  A rule on the column specifies "color: blue !important;"
  Its 'style' attribute specifies "color: green;"

  If indeed the 'style' attribute inherited, the table cells in that column
  would be green, not blue, because they now have style attributes that say
  "color: green" and only the style attribute was inherited, not the computed
  style. Were you to put text in the column itself, however, that text would be
  blue because the !important rule overrides the normal rule in the column's
  'style' attribute, setting the column's computed value for 'color' to 'blue'.

And yes, this is an invalid bug.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: