Closed Bug 915 (col-align-inherit) Opened 26 years ago Closed 5 years ago

implement inheritance of alignment attributes from columns (align, valign, char, charoff, (lang, dir)?)

Categories

(Core :: CSS Parsing and Computation, defect, P4)

defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: kipp, Unassigned)

References

(Blocks 1 open bug, )

Details

(4 keywords, Whiteboard: [patch]see comment 288 for work remaining to be done)

Attachments

(14 files, 4 obsolete files)

714 bytes, text/html
Details
616 bytes, text/html
Details
237 bytes, text/html
Details
695 bytes, text/html
Details
2.06 KB, text/html
Details
3.36 KB, text/html
Details
558 bytes, text/html
Details
771 bytes, text/html
Details
560 bytes, text/html
Details
1.35 KB, text/html
Details
82.29 KB, image/jpeg
Details
15.23 KB, image/png
Details
20.90 KB, patch
Details | Diff | Splinter Review
2.12 KB, text/html
Details
something about a missing colframe...
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
this was a small coding error on my part related to the new frame creation
strategy.  The content has a 4-column table, but provides only a single COL
(actually, just a COLGROUP with no SPAN attribute) so the table frame creation
code synthesizes the other 3 COLs.  The COLGROUP frame was getting an Init() for
the first COL, but not the other 3.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Using 11/30 devprev build. Re-opening bug. Behavior in the first column
heading is incorrect. Of the 4 column headings, only the first has a COLGROUP
element tag and it has a value of align=left; therefore, the first column
heading should align left (IT DOES NOT). The other column headings do not have
attributes and should slign to the default - center (they do).
Let me correct my comments. The COLGROUP element only spans one column which
would only apply to the 'Element' heading. This column heading should align left
and it does not.
Summary: this page triggered an assertion in the table code → column style resolution not yet implemented
changed summary to reflect the real problem.

see discussion summary at
http://warp/client/raptor/table_column_style_resolution.html
Assignee: buster → peterl
Status: REOPENED → NEW
*** Bug 1129 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M4 → M6
Target Milestone: M6 → M8
This one is going to be interesting. Peter, you may wish to suggest the the
CSS WG that the 'text-align' property for cells should inherit from their
columns/column groups, or something along those lines. I believe what we are
currently doing would be correct in terms of CSS2, if attributes could be
simply mapped to properties. But it is wrong in terms of HTML4.
Whiteboard: need to contact the WG for clarification
*** Bug 19040 has been marked as a duplicate of this bug. ***
Target Milestone: M16 → M15
*** Bug 24595 has been marked as a duplicate of this bug. ***
Keywords: beta1, css1
Adding 'beta1' to keywords. Beta1 should support CSS1 styles for all elements.
Pierre and I agree that we do need to get this fixed; if we don't, COL and 
COLGROUP are fairly useless. However, if push comes to shove, I'll be 
comfortable release noting this for beta 1 because (1) the W3C CSS1 test suite 
doesn't test this, and (2) no existing browser supports this, so there isn't 
existing content using it that will break. I think this is a "like to have" for 
beta 1 (but I wouldn't stop ship for it) and a "must have" for FC beta and FCS.
Putting on PDT- radar for beta 1.
Whiteboard: need to contact the WG for clarification → [PDT-]need to contact the WG for clarification
*** Bug 23995 has been marked as a duplicate of this bug. ***
*** Bug 7471 has been marked as a duplicate of this bug. ***
pierre/karnaze/troy: What was the WG's decision on text-align 'inherting' 
through columns in CSS like it does in HTML?

david: cc'ing you, you might be interested.
Keywords: css2
Blocks: 29055
Status: NEW → ASSIGNED
*** Bug 25935 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT-]need to contact the WG for clarification → [PDT-] still need to contact the WG for clarification
Updating summary to more accurately reflect the bug.
Summary: column style resolution not yet implemented → column style resolution for text-align not yet implemented
I'm CCing myself and attempting to summarize this bug after running into it in 
some work I was doing and spending time reading through it and the dups:

This bug is cause by a contradiction between the CSS2 spec and the HTML4 spec.

http://www.w3.org/TR/REC-CSS2/tables.html#q4 states that
"The following properties apply to column and column-group elements: 
'border', 'background', 'width', and 'visibility'"

However, http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4 permits the 
'align' attribute on COL and COLGROUP elements.  If the 'align' attribute is to 
be equated to the 'text-align' property, this contradicts the above secion of 
CSS2.

Mozilla's current behavior complies with the CSS2 spec, however because the 
'align' attribute does not inherit from COL/COLGROUP, it violates the HTML4 
spec.

Restricting column inheritance to such a narrow group of properties also appears 
to violate the intended purpose of the COL element, namely "The COL element 
allows authors to share attributes among several columns without implying any 
structural grouping."  Limiting the 'attributes' to those specified by CSS2 
greatly reduces the usefulness of COL/COLGROUP.  Moreover, code which relies on 
a wider range of columnar property inheritance is already extant, because IE 
supports it.  

A request for clarification to the W3C CSS working group is pending.
Moving off to M16 while we wait for clarification from the WG.
Target Milestone: M15 → M16
*** Bug 34814 has been marked as a duplicate of this bug. ***
Keywords: nsbeta2
Whiteboard: [PDT-] still need to contact the WG for clarification → still need to contact the WG for clarification
PDT- removed from beta1; nsbeta2 added.
sacolcor@provide.net: HTML align inherits from COL/COLGROUP, but CSS text-align 
doesn't inherit from COL/COLGROUP.
HTML align is not the same as CSS text-align. For example, HTML align can 
center the block-level element, but CSS text-align can't.
Having layout control attributes in HTML that cannot be emulated using CSS seems 
to violate the intended seperation between using HTML for structure and CSS for 
layout.  Is there a reason that text-align (and other properties) shouldn't 
inherit from COL/COLGROUP?
Yes.  Inheritance works over the document structure.  CSS doesn't know
beforehand what element is a column, or what is a cell, or what is a block. 
That is all determined by the display property.

If you propose general inheritance from COL/COLGROUP, what if I had the rule
COLGROUP { display: table-cell; }
?  Would the inheritance be determined by the element name or the display type?
IE seems to support cells inheriting from col and colgroup (at least color). 

Dave, are you saying that the specs don't support this type of inheritance in 
general or just for text-align.
I'm saying that in terms of CSS, it's wrong.  (Although perhaps there could be a
special exception for text-align on table-column elements...)  However, it's
required for HTML.
I can see the difficulties with 'display', however there are many properties 
(text-align, font, color, etc), that I can see authors wanting to apply on a 
columnar basis fairly frequently.  It now sounds like there is no way to 
accomplish this without breaking the 'HTML is not for presentation' rule.  Is 
there a 'good' way to resolve this dillema using current specs?  If not, are the 
working groups attempting to resolve it in a future one?
IE 5.5 for Windows supports inheriting of 'text-align' from COLGROUPs and COLs.
CSS2 Spec. 17.3 says that 'border', 'background', 'width', and 'visibility' 
apply to column and column-group elements.

(http://www.w3.org/TR/REC-CSS2/tables.html#q4 )
|Table cells may belong to two contexts: rows and columns. However, in the 
|source document cells are descendants of rows, never of columns. Nevertheless, 
|some aspects of cells can be influenced by setting properties on columns. 
|
|The following properties apply to column and column-group elements: 
|
|'border' 
(snip)
|'background' 
(snip)
|'width' 
(snip)
|'visibility' 

And CSS Spec. 9.10 says CSS 'direction' doesn't inherit from column, but 
HTML4 "dir" inherits from COL.
( http://www.w3.org/TR/REC-CSS2/visuren.html#direction )
|Note. The 'direction' property, when specified for table column elements, is 
|not inherited by cells in the column since columns don't exist in the document 
|tree. Thus, CSS cannot easily capture the "dir" attribute inheritance rules 
|described in [HTML40], section 11.3.2.1.

What about 'text-align'? Probably 'text-align' should not inherit from column 
and column-group since it is not listed in 17.3 as exception.

Win IE 5.5 is wrong. On MacIE 5, HTML4 "align" and CSS 'background' inherit 
from column, but CSS 'text-align' and 'color' don't inherit from column.
>On MacIE 5, HTML4 "align" and CSS 'background' inherit from column,

It was not accurate. On MacIE5, HTML4 "align" inherit from COL and 
CSS 'background' applys to column (but doesn't inherit from column).

CSS2 Spec. 17.3 is not relevant to inheritance.
If cell simply inherits 'background' from column, border-spacing would not be 
painted. But border-spacing should also be painted.
Attached file New testcase
| Win IE 5.5 is wrong. On MacIE 5, HTML4 "align" and CSS 'background' inherit
| from column, but CSS 'text-align' and 'color' don't inherit from column.

Does 'background' inherit from column? It really shouldn't. As a matter of fact, background should never be inherited (if you haven't asked for it by using 'background: inherit').When using 'background' on COLs and 'border-collapse: collapse', table celles should have a transparent background, which makes the background on COL(GROUP)s shine through.

In the same way, borders should *apply* to COLs, but not be inherited to cells.

IMHO, the best thing would be if 'text-align' *was* inherited from COLs, but this isn't stated in the CSS specification (or in the errata). So, if 'text-align' on columns isn't meant to be inherited (something which isn't entirely clear), I think the CSS-WG should consider this for a future errata/CSS 3.
This is another COL/COLGROUP not yet implemented in CSS bug. According to the 
logic expressed in bug 29055, this is being moved out since it won't get into 
beta2.

See bug 29055.
Keywords: beta1helpwanted
Priority: P2 → P3
Target Milestone: M16 → Future
*** Bug 38917 has been marked as a duplicate of this bug. ***
Keywords: testcase
Blocks: 43178
*** Bug 43727 has been marked as a duplicate of this bug. ***
*** Bug 44981 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
*** Bug 50017 has been marked as a duplicate of this bug. ***
*** Bug 49995 has been marked as a duplicate of this bug. ***
*** Bug 49997 has been marked as a duplicate of this bug. ***
Turns out in HTML you can have the 'valign' attribute on COL as well. This 
would need to be mapped to the equivalent of 'vertical-align'.
Summary: column style resolution for text-align not yet implemented → column style resolution for text-align,vertical-align not yet implemented
*** Bug 50003 has been marked as a duplicate of this bug. ***
*** Bug 50004 has been marked as a duplicate of this bug. ***
*** Bug 49994 has been marked as a duplicate of this bug. ***
*** Bug 50019 has been marked as a duplicate of this bug. ***
*** Bug 49994 has been marked as a duplicate of this bug. ***
*** Bug 50020 has been marked as a duplicate of this bug. ***
*** Bug 50022 has been marked as a duplicate of this bug. ***
*** Bug 50023 has been marked as a duplicate of this bug. ***
*** Bug 50023 has been marked as a duplicate of this bug. ***
Summary: column style resolution for text-align,vertical-align not yet implemented → column style resolution for text-align,vertical-align not yet implemented [CASCADE]
*** Bug 51201 has been marked as a duplicate of this bug. ***
I believe this is not a CSS1 bug, since CSS1 did not describe tables - CSS2 and
HTML4 though.
Keywords: css1html4
Blocks: 43997
No longer blocks: 43997
Have we contacted the "WG" for clarification yet? If so, did we receive any?

Can we get rid of that in the status whiteboard if we have contacted them?
No, we haven't, mainly because we have no proposal to give to them. However I do
intend to get to it at some point...
Whiteboard: [nsbeta2-][nsbeta3-] still need to contact the WG for clarification → still need to contact the WG for clarification
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.
Keywords: nsbeta1
ekrock: Are you sure this is an nsbeta1 candidate? I understand this is going
to require a significant amount of work for only medium gain. The support that
this bug would provide is for deprecated attributes. Wouldn't we be better off
spending our CSS effort on footprint, performance and float-related bugs?
Keywords: highrisk, mozilla1.0
hixie: Why do you think <col align="center"> is deprecated? This is in the
strict HTML4 and XHTML1 specs, AFAICS. And Mozilla does not render that
correctly (see testcases 3 & 4).

Or are you talking about other attributes?
Hixie, I don't see what "deprecated attributes" you are talking about... except
from the align attribute. The style attributes and CSS value inside them should
not be deprecated, as much as I know... Sorry if I missed something...
Oops, my apologies. "align" and "valign" are not yet deprecated.

Erich: Per CSS, <col style="text-align:right; vertical-align:bottom"> should 
have no effect. This is purely an HTML thing. See CSS2, section 17.3.
reassigning to glazman and marking m1.0.
Assignee: attinasi → glazman
Status: ASSIGNED → NEW
QA Contact: chrisd → amar
Target Milestone: Future → mozilla1.0
I don't understand this assignment. Does it mean that a dual inheritance is
expected in CSS tables ? I was a member of the CSS WG when it designed CSS2 and
I am pretty sure that the CSS WG will not accept dual inheritance from TR and
COL/COLGROUP.

The list of properties applying to COL and COLGROUP has been voluntarily
restricted to border, background, width and visibility, and the others have
been voluntarily excluded from the list because of implementation concerns
and difficulty of the model if we allow 'text-align' to apply for instance.

Just for the record, I implemented such a dual inheritance for CALS tables (and
HTML tables derive from CALS) in a former life and it was a nightmare.

Please confirm if you want me to raise the issue (even if I am pessimistic) in
the CSS WG.

About the HTML issue which is the original purpose of this bug, this goes beyond
my actual knowledge of the cascade implementation and raises a new question :
what is the specificity of an HTML alignment specified on a COL/COLGROUP ? A
cell in a column is not, structurally speaking, a descendant of the column...

  * w

Daniel: This bug is only about the implementation of the HTML 4.0 Transitional 
attributes. Their specificity is zero per CSS2. We implement that using the 
"mapped attribute" stuff in element classes.
Doesn't seem like this should be hacked at any CSS level.  Seems like the table 
code should just check this special case when it queries for alignment WITHOUT 
actually mutating the style context data for a cell.
*** Bug 77466 has been marked as a duplicate of this bug. ***
*** Bug 77465 has been marked as a duplicate of this bug. ***
IMHO, dual inheritance of table cells is fully corresponding to common sense.
Logically, table is a 2D matrix, which has both peer dimensions. Therefore, all
CSS attributes of <COL> must be inherited in corresponding cells.
Blocks: 104166
Did Microsoft voluntarily exclude "color" (IE supports it)? Tables can only 
implement inheritance that stops at the cell. IE's implementation of foreground 
color applies to all elements below the cell. 

This issue has been unresolved for 3 years. If it is so difficult to implement 
at the style system level, I wonder how IE does it. 
This issue has been unresolved for years because nobody has yet come up with a
theoretical proposal explaining how things *should* work.  If you do that, then
maybe we could discuss how hard it would be to implement.  But until that
happens such discussion is meaningless.
I think IE is following a very simple (and intuitive) strategy for "color" by 
considering <tr> inheritance as primary and <col> inheritance as secondary. IE 
lets a <td> (that has no matching non-user-agent [nua] color rules) inherit 
color from its <col> (if there are matching nua color rules) if there are no 
matching nua color rules on its <tr>. It could get more complicated by 
considering inline vs external style, important, user vs author, but I'm not 
sure how IE handles that. So, I guess an important rule on the <col> would win 
out over a normal rule on the <tr>. 

That's my proposal.
Basically, what you are saying is "TD inherits from COL if there is nothing on 
TR" which comes down to a regular inheritance chain "COL -> TR -> TD".

I don't understand why you mention "non-user-agent" rules.  Also things should 
not get more complicated with important rules and/or external style.  Don't let 
IE confuse you as it did for me again in bug 103596.  We inherit computed style 
(duh), not style rules.

Anyhow, I thought that this bug was about the inheritance of HTML attributes, not 
CSS style. From a style standpoint, things are fairly well defined.
*** Bug 51693 has been marked as a duplicate of this bug. ***
*** Bug 111835 has been marked as a duplicate of this bug. ***
Shouldn't OS be changed to all? At least I have that problem on Linux (2001120221).
OS: Windows NT → All
Hardware: PC → All
*** Bug 114341 has been marked as a duplicate of this bug. ***
*** Bug 115504 has been marked as a duplicate of this bug. ***
*** Bug 123001 has been marked as a duplicate of this bug. ***
Moving from Moz1.0 to future-P1.  All bugs scheduled for Moz1.0 need to
nominated using the nsbeta1 keyword.
Priority: P3 → P1
Target Milestone: mozilla1.0 → Future
not critical for mozilla1.0
Keywords: mozilla1.0mozilla1.0-
*** Bug 139569 has been marked as a duplicate of this bug. ***
Here is a proposal:

HTML4 specification section 11.2.4 says that %attrs; (including STYLE) are valid
attributes of COL and COLGROUP.  All CSS properites that have "Applies to: ALL"
should apply to COL and COLGROUP.  
HTML4 specification section 11.3.2 describes an order of precedence for
inheriting attributes (VALIGN, LANG, DIR, STYLE) by content and children of TD
such as P.  NOTE there is a different order of precedence for attributes ALIGN,
CHAR, and CHAROFF.
This order of precedence should apply to all CSS properties that have
"inheritence: YES".  

And to be perfectly clear, all CSS properties that have "inheritence: YES" and
"Applies to: ALL" should apply to all HTML table elements (including TABLE,
COLGROUP, COL, TBODY, TR, TD) so they may be inherited by the content and
children of TD.

That is my proposal.  I think this bug should be fixed for Mozilla 1.2 if not
sooner.

I agree with comment #81.  You cannot apply a strict tree model for inheritance
in a table because a table is fundamentally a matrix (2D), not a linear tree.
Otherwise it's just a fancy list of lists.  Apparently the folks at Microsoft agree.

What about CSS2 section 17.3?  I think the properties listed there (BORDER,
BACKGROUND, WIDTH, VISIBILITY) are intended to apply to the column as a whole
element and probably not be inherited.  Infact, CSS2 explicitly describes this
for BACKGROUND and I think the same behaviour should work for BORDER.  Therefore
this section excludes ONLY these properties from inheritance by TD.  This
restriction should not apply to other CSS properties that apply to ALL elements
and can be inherited.  
That proposal contradicts section 6.1.1 of CSS2 (and also 6.2), which says that
inheritance works on the document tree.  If this is fixed, it should be fixed
only for HTML (unless the CSS spec is changed, which I think is unlikely).

I think this should be fixed by implementing HTML4 11.3.2 in the attribute
mapping code, and always applying the mapping to the cell rather than relying on
CSS inheritance.  Note that this makes dynamic changes tricky.
Actually, all we'd really need to put in the cell attribute mapping code would
be alignment for the cell and for the col and colgroup.
I take back the comment about attribute mapping.  It would have to be a
specialized rule managed by HTMLStyleSheetImpl that matched relevant TD elements
and overrode the attribute mapping for TD.
I could live with an exception for (X)HTML, but not just for alignment. It
should be for every CSS1(2?) property that applies to all elements and that
inherits, unless there are some properties that should not be included for
specific reasons.

Thank you for referring me to section 6.2 of CSS2.  After re-reading the
definition of the document tree and the inheritance rules, I now understand why
this behavior is not valid CSS2.  

This is in response to comment #84 asking for a proposal for how things *should*
work so that it could be discussed.    In the scope of HTML, I think TD *should*
behave this way regardless of what CSS2 says.  HTML4 is not perfect. CSS2 is not
perfect.  They disagree on TD.  Therefore a "better" browser may choose the
"better" way of doing things.  Yes, this opens the pandora's box of opinions on
what is "better".  Maybe it contradicts CSS2, but IE sets a precedent that makes
very good sense to me.

The HTML4/CSS2 model is supposed to separate the structure of a document from
it's stylistic formatting.  So why does CSS2 impose the structural rule that
each element may have exactly one parent?  With this rule in place CSS2 is
inadequate to style the contexts of a two-dimensional table.  HTML is supposed
to describe the structure of a document, and it says a TD can inherit style from
more than one "parent" element.  

Regarding document structure, I think (X)HTML should trump CSS2.

Besides, common sense agrees with HTML4 and not CSS2.  A TD element needs to
have two "parents" in order to illustrate it's relationship to the two axes of
the table.  TD and TH may be unique in HTML in this respect.  One "parent" has
priority over the other.  HTML specifies that rows trump columns.  
would not section 17.5.1 suggest an unambiguous inheritance hierarchy?

http://www.w3.org/TR/1998/REC-CSS2-19980512/tables.html#table-layers

-matt
which, by the way agrees that rows trump columns. So, it seems HTML and CSS are
in agreement

-matt

Re comment 101:  Absolutely not.  Background properties are not inherited.  They
draw on top of each other.
regarding comment 101:


While its true mozilla doesn't draw backgrounds the way CSS2 17.5.1 says, this
bug 915 doesn't concern backgrounds or other properties that are not normally
inherited.  Table backgrounds in mozilla are covered by bug 4510.

css2 doesn't seem to allow inheritance from COL to TD.  (X)HTML does.  I think
the principle of CSS2 17.5.1 should be applied to inheritable properties.  
*** Bug 145250 has been marked as a duplicate of this bug. ***
*** Bug 147931 has been marked as a duplicate of this bug. ***
Whiteboard: still need to contact the WG for clarification → still need to contact the WG for clarification[HTML4-11.3.2]
Blocks: 2068
*** Bug 168663 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0-
*** Bug 176338 has been marked as a duplicate of this bug. ***
Here's my 2 cents.

Re:comment #86: "TD inherits from COL if there is nothing on 
TR which comes down to a regular inheritance chain COL -> TR -> TD". How about
letting only text-align inherit from COL and COLGROUP and let vertical-align
inherit from TR? That's how I would implement this. There would be no conflict
to resolve.

Re: comment#100: One "parent" has priority over the other.  HTML specifies that
rows trump columns. I believe this is what CSS2 also says when both x and y axis
are involved like borders. Here's an illustration of this in 17.6.2:
"If border styles differ only in color, then a style set on a cell wins over one
on a row, which wins over a row group, column, column group and, lastly, table"

I agree also that HTML align is quite different from the css property
text-align. HTML align often implies positioning the element within its
immediate parent node; text-align implies text alignment of the text node within
the node. The css equivalent of HTML align in block-level elements involves the
margin property, not text-align. So, within this way of definition terms, within
this frame of understanding, <col align="left|center|right|justify|char"> does
not strike me as "natural". I believe this whole issue would be a lot easier to
solve if HTML align, char, charoff attributes would be deprecated for COL,
COLGROUP and TR and css properties only would be applied.
I would also deprecate valign for COL, COLGROUP and TR.

HTML COL         CSS prop.             HTML TR
--------         ---------             -------
align            text-align            align
char             text-align:<string>   char
charoff          ?text-indent?         charoff
valign           vertical-align        valign


First(left) and last(right) columns would be deprecated; only way to style a
table would be to use the middle column. CSS prop. text-align and text-indent
would apply to COL, COLGROUP only while vertical-align would apply to TR only.
(Of course the TDs would have the final word in the inheritance propagation on
text-align, text-indent, vertical-align properties.)

In other words, a text-align property applied to a td would only inherit from
its COL or COLGROUP while a vertical-align proprerty applied to a td would only
inherit from its TR.

Please tell me if I'm making sense...
I could present my reasoning/thinking/model in a demo... it would better
illustrate all this.
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.
Rules (using collapsing borders) on row/col groups was fixed by bug 41262 more
than 8 months ago.
drunclear:  two things

1: I don't agree with your suggestion for the mozilla developers to depreciate
and never support HTML4 align and valign.  HTML4 development is basically
closed, right?  So either mozilla will try to support HTML4 100% or it will not.
 I would like to see at least one version of mozilla format HTML4 tables 100%
correctly before they depreciate parts of HTML4 for good.  But this is just my
opinion.

2: I would really like to see your examples.  In particular I don't understand
how the text-align properties are going to inherit from <col> using the CSS2
model, so I would like to see it in action.  Thank you.
*** Bug 183917 has been marked as a duplicate of this bug. ***
Flags: blocking1.3a?
Blocks: robin's
Status: NEW → ASSIGNED
*** Bug 193843 has been marked as a duplicate of this bug. ***
'background-color' on COL is *not* related to this bug, but may be related to
bug 4510.  This bug covers implementation of HTML's alignment attributes on COL
and COLGROUP, for which HTML describes an inheritance algorithm that differs
from CSS (and perhaps a general solution to what happens to inherited properties
specified on COL or COLGROUP that would be nonconformant to CSS).
Attached file Testcase for text-align (obsolete) —
Showing a table in CSS2 and HTML 4.01 Transitional
Verified w3.org valid(HTML and CSS2)
Comment on attachment 115425 [details]
Testcase for text-align

The 'text-align' stuff in this testcase is not valid, since CSS inheritance
works by the content tree.
Attachment #115425 - Attachment is obsolete: true
on comment #123
I posted the attachment #115425 [details] because:
- the Status Whiteboard sugest this is a non resolved issue
- the summary list text-align
- it works on IE 6.0SP1 (now I know that this issue is not well defined in CSS2,
so this my be a IE hack)
I used all previous testcases(minus the height testcase) in this bug to make
this simple testcase where people can compare what IE does. 
I don't think IE correct, but since there is no patch and no definitive
solution, I wanted to show what IE does.
Blocks: majorbugs
*** Bug 202998 has been marked as a duplicate of this bug. ***
IE also support align and style, set in "col"
Note that Safari v1.0b2 (v73) [kHTML based] renders honors the CSS background-color property in 
<a href="http://bugzilla.mozilla.org/attachment.cgi?id=115446&action=view">this testcase</
a>, and no other CSS attributes. Strongly request that CSS attributes flow to the TD elements, 
otherwise a great opportunity for functionality is lost.
Is there a projection on when this bug will be resolved (one way or the other), 
and what still needs to be done?

Anyway, I second #116:

"This bug has gone on for almost 2 years. Quit the debate. Pick a direction and
go with it."
In the abscence of a clear standards-based direction (which it seems obvious
that we have), I believe that this should be resolved toward compatibility with
existing technology.  Both IE and Safari have been mentioned as supporting
similar cases, so let's just accept it as a defacto standard and implement it.
I described how this should be done in comment 97, comment 98, and comment 99. 
If somebody is willing to write a good (i.e., acceptable to the module owner and
peers) implementation or hire somebody to write a good implementation, then the
bug will likely be fixed.  However, beyond that, see point 2 in
http://bugzilla.mozilla.org/page.cgi?id=etiquette.html .
I chatted to dbaron about this and it seems a better solution would be to
introduce new values for text-align and vertical-align (and theoretically
possibly direction and lang) and have those values compute to either the HTML
values based on the attributes present, or inherit the parent element's value,
during the cascade, and then set

   td, th {
     text-align: -moz-table-cell-rules; 
     vertical-align: -moz-table-cell-rules;
   }

...in the UA stylesheet.

The exact computation for 'text-align: -moz-table-cell-rules' would be:

   If align is set on the element, use that, else
   if align is set on the appropriate <col>, use that, else
   if align is set on the appropriate <colgroup>, use that, else
   if align is set on the parent <tr>, use that, else
   if align is set on the ancestor <tbody>/<thead>/<tfoot>, use that, else
   if align is set on the ancestor <table>, use that, else
   if the element is 'td', inherit text-align from the parent element, else
   the element is 'th', use 'center'.

The exact computation for 'vertical-align: -moz-table-cell-rules' would be:

   If valign is set on the element, use that, else
   if valign is set on the parent <tr>, use that, else
   if valign is set on the ancestor <tbody>/<thead>/<tfoot>, use that, else
   if valign is set on the appropriate <col>, use that, else
   if valign is set on the appropriate <colgroup>, use that, else
   if valign is set on the ancestor <table>, use that, else
   use 'baseline'.

Then, we would remove attribute mapping for 'align' and 'valign' from <tr>,
<tbody>, <thead>, <tfoot>, <col>, <colgroup>, and <table>. (We can leave it for
<td> and <th>, since that then implies that we can skip the first test in the
two lists above.)


Now, from an implementation point of view, my mail problems are first of all,
working out where computations happen, and secondly, how to determine which
<col> applies to which <td> without highly inefficient walking around the DOM
during the cascade. This also has to be able to cope with dynamically inserted
<col> elements and stuff.

Any suggestions would be very welcome. :-)
nsRuleNode.cpp, nsRuleNode::ComputeTextData and nsRuleNode::ComputeTextResetData
seem to be the relevant functions.
One problem would seem to be that style contexts can (at least theoretically) be
shared across elements with differing attributes or ancestors, and there is thus
no way to check the attributes from the functions mentioned above.
One way of doing this would be to add two new internal properties, much like I
think we do for 'lang', say '-moz-table-align' and '-moz-table-valign', which
are non-inherited properties mapped from attributes, and then the
'-moz-table-cell-rules' value on 'text-align' and 'vertical-align' would use
those. So then the proposal becomes:

ua.css would contain:

   td, th {
     text-align: -moz-table-cell-rules; 
     vertical-align: -moz-table-cell-rules;
     -moz-table-valign: baseline; /* initial value */
   }
   td { -moz-table-align: use-inherit; } /* initial value */
   th { -moz-table-align: center; }

Cells would then set their '-moz-table-align' value from attributes as follows:

   If align is set on the element, use that, else
   if align is set on the appropriate <col>, use that, else
   if align is set on the appropriate <colgroup>, use that, else
   if align is set on the parent <tr>, use that, else
   if align is set on the ancestor <tbody>/<thead>/<tfoot>, use that, else
   if align is set on the ancestor <table>, use that, else
   leave it.

...and they would set '-moz-table-valign' as follows:

   If valign is set on the element, use that, else
   if valign is set on the parent <tr>, use that, else
   if valign is set on the ancestor <tbody>/<thead>/<tfoot>, use that, else
   if valign is set on the appropriate <col>, use that, else
   if valign is set on the appropriate <colgroup>, use that, else
   if valign is set on the ancestor <table>, use that, else
   leave it.

In addition, we would remove attribute mapping for 'align' and 'valign' from
<tr>, <tbody>, <thead>, <tfoot>, <col>, <colgroup>, and <table>.

The 'use-inherit' value would cause 'text-align' to inherit its value from the
parent element.


The disadvantages with this idea are that it is ridiculously convoluted and will
take either lots of memory (two new properties and cached values for the
attributes) or lots of CPU (every time the table is changed we need to
recalculate all of this) or both, for what is frankly a deprecated feature with
limited use.

Can someone think of an easier/better way?
bernd just pointed out to me that there's some '#ifdef 0'ed code for this at:
http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/nsTableCellFrame.cpp#1133

It fails to handle cases such as 

  tr { text-align: center; }
  <tr align="right"> <td> this should be right aligned </td> </tr>

...but does help me since now I know there are easier ways of mapping table
related attributes from columns. :-)

It doesn't really solve the "dynamicness" as far as I can tell though; is there
a way to say that attribute changes on the column should instead affect the text
and vertical alignment of cells in that column?
Hixie: I doubt that in this case the text should be right aligned (or that it
is well defined enough)
According to my reading of the HTML and CSS specs, they should all be right
aligned, because the TR's attribute is equivalent to a selector that affects the
cell, and there's no CSS anywhere to override it.

I wouldn't mind making this a quirk, though.

dbaron: What do you think? Should we be as strict as my interpretation? Or do
you disagree with my interpretation?


In any case, I was thinking about how to solve this, and I think I missed a step
in my previous musings. As far as I can tell, we could actually do everything I
described above without using any special values at all, just by moving all the
attribute mapping code to the cells instead of the rows, columns, tables, etc.
And in quirks mode we could still map the table, row group, and row attributes
if required.

Now, this is exactly what dbaron suggested in comment 97. dbaron: Can you
remember why you changed your mind about how to fix this back then? I can't
really see any obvious reason to.
> Now, this is exactly what dbaron suggested in comment 97. dbaron: Can you
> remember why you changed your mind about how to fix this back then? I can't
> really see any obvious reason to.

Attribute mapping is based on creating a single style rule for any unique set of
attributes on an element.  What we want to do here might vary depending on the
attributes of ancestors.

Comment on attachment 125172 [details]
testcase css vs html attributes

I think a literal interpretation of HTML4 leads to the conclusion that these
should be center, center, and right, although if all the cells had STYLE=""
attributes+values then they should all be right aligned.

I think it's worth asking the HTML spec authors what they really meant before
going ahead with anything that ridiculous, though.
Having looked at several different ways of implementing this, I can't see any
sensible way of doing it without adding significant overhead that is simply not
warranted by the rarity of this feature, especially given that it is deprecated,
and that UAs that do implement this don't even do it according to the spec.

This appears to be the only place in Gecko where attributes from elements that
are only distant cousins need to be mapped to stylistic properties that do not
affect the frame construction.

Unless someone can come up with some workable solution, I'm going to effectively
consider this WONTFIX.
Priority: P1 → --
Whiteboard: still need to contact the WG for clarification[HTML4-11.3.2] → need to contact the WG for clarification [HTML4-11.3.2]
I wouldn't call this a rarely used feature as a large number of business 
applications are about displaying tabular data. And the easy way to align for 
example a price column is to set a style (either inline or through a class) on 
a COL element instead of setting it on each TD separate.
Which has nothing to do with this bug.  This bug is about the "align" attribute
on <col> elements in the HTML.  In fact, you cannot align everything in a column
at all using CSS -- see http://www.w3.org/TR/CSS21/tables.html#q4 (and comment
27 in this bug).

Fwiw, comment 77 may be the most reasonable solution, if we can decide on
precedence issues (eg, does an !important rule on <td> override the align
attribute on the <col>?  If so, how do we detect that?).
> And the easy way to align for example a price column is to set a style (either 
> inline or through a class)

Setting it through a class shouldn't work according to the specs. The only thing
that should work is setting it through the 'align' (and 'valign') attributes.

In any case I'm not saying that I wouldn't like to see this fixed; I'm just
saying I cannot see any sensible way of fixing it given Mozilla's current
architecture, and I don't see that this issue warrants architectural changes.
The benefits just don't outweigh the costs.
No longer blocks: 2068, 43178, 98694, 104166
> Fwiw, comment 77 may be the most reasonable solution

The problem with comment 77 is that the table code isn't the code that queries
the text-align property. The block and line box code is. (As far as I can tell.)


> if we can decide on precedence issues (eg, does an !important rule on <td> 
> override the align attribute on the <col>?

Any explicit CSS on the <td> should override all attributes, whether !important
or not, because the HTML attributes should be treated as CSS rules at the top
(lowest specificity and earliest order) of the author level of the cascade.
Yes, but the table code has no knowledge of the cascade.... so it has no way to
tell, e.g., style set via ua.css from style set via inline style, from nothing
set at all.  So _if_ we try to do this via the table reflow code, _then_ we need
to give style system consumers a way to determine the "origin" of the computed
style.

Truth be told, we could use such origin-determination anyway; if we had it, we
could greatly simplify (and make more correct, probably) the nsITheme styling of
form controls.
> ... that is simply not
> warranted by the rarity of this feature, especially given that it is 
> deprecated, ...

Ian: Align/valign for COL, COLGROUP, TH, TD, THEAD, TBODY, TFOOT and TR is NOT
deprecated by HTML4.01 specification. Or do you mean anything other?
adam: Presentational attributes in general are deprecated in favour of CSS,
although I will grant you that the explicit text of the specification may not
always call this out. In any case, such attributes will not be found in XHTML2.
> In any case, such attributes will not be found in XHTML2.

6: We are not there yet.  
5: When we get to XHTML2 there still needs to be a way to align columns of data.
 (CSS3?)  
4: HTML4 and XHTML1 will be around a long time.
3: CSS2 cannot do it.
2: This is not a rare or a new feature.  Many programs that present table data
have methods to align the data columns.  Not mozilla!
1: 63 votes

so...  the bug should be fixed.  
charles allen:

> so...  the bug should be fixed.  

Are you volunteering?


> CSS2 cannot do it.

CSS could, actually, you just need to select the cells rather than the columns.
*** Bug 29055 has been marked as a duplicate of this bug. ***
Bug #29055 was "Resolved" as a duplicate of this one.  #29055 had a Severity of
"major".  Further, the workaround requires setting either an attribute or class
in EACH cell of an affected column, which is a burden for large tables.  Thus,
this bug should be "major".  

See my comment #26 for bug #29055 for a test case.  
*** Bug 228895 has been marked as a duplicate of this bug. ***
*** Bug 229798 has been marked as a duplicate of this bug. ***
*** Bug 233052 has been marked as a duplicate of this bug. ***
*** Bug 235071 has been marked as a duplicate of this bug. ***
Alias: column
Keywords: qawanted
QA Contact: madhur → ian
*** Bug 240096 has been marked as a duplicate of this bug. ***
*** Bug 240096 has been marked as a duplicate of this bug. ***
*** Bug 240096 has been marked as a duplicate of this bug. ***
Summary: column style resolution for text-align,vertical-align not yet implemented [CASCADE] → column style resolution for text-align,vertical-align not yet implemented [CASCADE] (<col align>)
Summary: column style resolution for text-align,vertical-align not yet implemented [CASCADE] (<col align>) → column alignment resolution not implemented (text-align,vertical-align styles, <col align>) [CASCADE]
Contrary to comments made in Bug #240096 for closing it as a duplicate of this
bug, the changes to the summary clearly indicate this is a CSS bug.  Which is
it, CSS or HTML?  

This bug is over five years old.  There are now 95 votes for this bug.  It has
been cited for closing over 40 other bug reports as duplicates of this one (5 so
far this year).  When will it be assigned for correction?  (No, I am a software
tester -- over 35 years experience and now retired -- not a software developer.
 I am not capable and not volunteering.)  
This bug is about implementing <col align> and related attributes and elements,
not about any CSS feature, although several of the duplicates are actually
requesting CSS features that basically boil down to the same thing. That is why
this bug's scope is a little vague.

An unusually large number of people, ranging from layout engine newbies like
myself to ridiculously clever people like dbaron, have looked at this bug, and
have utterly failed to determine any way in which it could be fixed without a
significant hit to the overall performance and/or memory footprint of the
rendering engine. Since the feature in question has been deprecated for some six
years, rearchitecting Mozilla so that fixing this becomes possible without such
a high cost is not a high priority.

Note that Mozilla is not an HTML user agent, it is a CSS user agent that happens
to have knwoledge of some HTML semantics. Thus when the two specifications
conflict, as they do in this case, CSS has priority in deciding for which
specification the design should be optimised.

Also note that IE's support of this property is at the cost of not implementing
a large section of CSS2. I explained this in more detail on my blog once:

   http://ln.hixie.ch/?start=1070385285&count=1

(Note to possible volunteers: IE does not follow the HTML specification on this
any more than it follows the CSS specification, but in this case it is likely
that if you just implemented what IE does as far as these attributes go, and did
not do the full HTML-spec version, the patch would still be accepted.)

The number of votes on this bug will not affect whether this bug is fixed or
not. Nor will high numbers of duplicates. We know it is a major bug, that's why
so many people have tried to fix it. The only thing that can affect that is
someone volunteering to fix it and doing so in a way that does not negatively
effect page load performance, memory footprint, or our existing CSS compliance.
Summary: column alignment resolution not implemented (text-align,vertical-align styles, <col align>) [CASCADE] → column alignment resolution for <col align> not implemented (text-align, vertical-align styles on columns) [CASCADE]
Whiteboard: need to contact the WG for clarification [HTML4-11.3.2] → SEE COMMENT 162 | need to contact the WG for clarification [HTML4-11.3.2]
(In reply to comment #162)

The blog entry seems to suggest that CSS2 on the one hand requires the graph of
inheritence relationships to be a directed tree (with edges from ancestors to
descendatns), and on the other hand necessitates, due to column inheritance, a
inheritence relations graph which is a DAG (i.e. can have edges from vertices to
non-pancestor edges while not forming cycles). So which is it? What does the
standard actually require? Or is there an internal contradiction?

Also, the blog entry seems to suggest more such cases become relevant in CSS3;
could it not be the case that entry resolution using a DAG instead of a
heirarchical tree will eventually be forced upon us (ok, ok, upon you)
regardless of whether we like it or not (performance- and footprint-wise)?
I can't see where has this been deprecated, according to W3C technical report 
at http://www.w3.org/TR/html4/struct/tables.html#h-11.3.2 alignment attributes 
are not deprecated on table elements.

But if Ian is right and Mozilla is not supposed to be an HTML agent then it 
changes everything...
Please explain how the horizontal or vertical alignment of table cell contents
specified via the col or colgroup elements is deprecated (per comment #162) when
both alignments are specified in the HTML 4.01 Strict DTD without any such
qualification.  
Using presentational HTML of any kind is deprecated. The only reason those 
specific attributes aren't labelled as such is that in 1997 when the spec first 
came out, CSS1 couldn't do tables. There's a note to this effect in the 1998 
second edition but true to HTML form, it fails to actually explicitly deprecate 
anything.

If you ask the HTML working group, though, they will happily tell you that yes, 
any use of HTML for presentational purposes is deprecated.
So, the HTML folks say that it's presentational, and therefore a CSS problem,
and the CSS folks say that it's not strictly heirarcical, and therefore not a
CSS problem.

I'm not sure this is purely presentational. Without real cell-typing (numeric,
date, boolean, text), alignment is about as close as possible. It certainly is
no more presentational than "char" or "charoff" or "colspan". One could make the
argument that specifying tabular layout of data is presentational, but I don't
think that argument would be taken well.

The CSS group agree that it is a CSS problem. They just haven't solved it yet.
Ian, I think Mozilla developers should follow W3C's way of thinking about 
this - support presentational HTML (at least on table columns) until there's a 
CSS way to do it (but judging from the comments here I doubt that there ever 
will be, that's why I think Mozilla should support the HTML way of doing this).
Yes, we all agree that this should be fixed. But see comment 162.
The comments about performance are a little misleading here, by the way.  
While I'm not disputing that there would be a performance hit if we accepted 
something like the alignment attribute, that would be a hit compared to having 
unaligned data.  It should be compared to the extra time taken if there were 
alignment properties/classes set on every single cel in the column - and some 
consideration should also be given to the additional server time and pipe 
bandwidth (and therefore overall time) given to that solution.  At least, 
that's the way I see it.
*** Bug 244845 has been marked as a duplicate of this bug. ***
*** Bug 245939 has been marked as a duplicate of this bug. ***
*** Bug 246461 has been marked as a duplicate of this bug. ***
The difficulty seems to stem from the desire to have styles on a table cell
inherited from a col tag that is not an ancestor of the cell in the document
object tree.  Is it at all possible to make the col tag behave less like a
separate element and more like an attribute of the parent table element that
contains it?  If the table somehow stored the styles defined on its col tags,
then the cells in that table could inherit from the table tag since it is a
direct ancestor.  Also, that would allow inheritence to work in the expected
order: table, col, tbody, tr, td.  Any thoughts on that?
(In reply to comment #175)
> The difficulty seems to stem from the desire to have styles on a table cell
> inherited from a col tag that is not an ancestor of the cell in the document
> object tree.  Is it at all possible to make the col tag behave less like a
> separate element and more like an attribute of the parent table element that
> contains it?  If the table somehow stored the styles defined on its col tags,
> then the cells in that table could inherit from the table tag since it is a
> direct ancestor.  Also, that would allow inheritence to work in the expected
> order: table, col, tbody, tr, td.  Any thoughts on that?

This is exactly the way i see the things. The cell is the ultimate child and
should inherit from all the parents. I also agree with the order: table,
colgroup, col, tbody,tr,td .  (colgroup is col's parent)
Comment 175 and comment 176 don't help anything.  The whole problem is that it's
not possible in the CSS to inherit from more than one parent and nobody has
described anything resembling a vaguely sensible way of doing so.
(In reply to comment #177)
> Comment 175 and comment 176 don't help anything.  The whole problem is that 
it's
> not possible in the CSS to inherit from more than one parent and nobody has
> described anything resembling a vaguely sensible way of doing so.

The whole of CSS involves cascading through multiple parents - whole ancestral 
hierarchies. Moreover, these hierarchies are complex, as ancestors may receive 
attributes through various types of rules of varying specificity. This "it's 
not possible" (like most!) is I think designed to stifle rather than to 
encourage creative discussion.

With the complex inheritance picture in CSS, surely the issue is one of 
priorities. CSS already has procedures for resolving priorities; for example, 
an attribute prescribed by a more remote ancestor may be overridden by a more 
proximal one (e.g. a DIV attribute may be overridden by a P attribute).

As many commentators have said, COLs and COLGROUPs complicate the picture 
because they don't fit the DOM tree like other CSS properties. Nevertheless, 
they do provide a natural way to prescribe those horizontal layout properties, 
i.e. width and alignment, that programmers need to provide in tablular reports. 
Some of us, who have to do a lot of tabular reports and who don't like writing 
repetitive cell-by-cell alignment attributes on every line of an n-line table, 
take the view that COL or COLGROUP is the natural way to do these things. 

So, what is the problem? In particular, if COL can be implemented for width (as 
the powers-that-be have decreed it should), what is the problem with 
implementing it for alignment also?

To claim (as has been claimed for years in this topic) that this is an 
inheritance problem seems to me unfounded.

If it is an inheritance problem, why can COL and COLGROUP be successfully used 
to specify width?

And what is this inheritance problem that uniquely affects alignment? - Let me 
see if I have this straight. Consider the example:

Assumption 1: Cell (3, 2) is at column 3, row 2.
Assumption 2: Column 3 prescribes text-align right.
Assumption 3: Row 2 prescribes text-align left.

If I understand the inheritance problem correctly, then Cell (3,2) could 
arguably be left-aligned (inheriting from Row 2) or right-aligned (inheriting 
from Column 3).

Baron et al seem to be alleging that in the absence of a definitive ruling from 
W3C, there is absolutely nothing that a user agent (e.g. Mozilla) can 
reasonably do except wash its hands of the whole business and wait for 
interminable deliberations of the appropriate international committees.

Yet several previous commentators have pointed out that one could use some 
consistent principles of logic, e.g. that COL has precedence over TR on 
horizontal attributes (e.g. width, text-align) while TR has precedence on 
vertical ones (e.g. height, vertical-align).

But first of all, let's consider the (usual, in fact typical) situation where 
there is no conflict between row attributes and column attributes on column 
width or alignment.

Although COL cuts across the DOM tree - columns intriniscally do - as a matter 
of fact all user agents already manage to harmonize respective column widths 
from row to row; so if it is not beyond the wit of man to give them equal 
width, why not common colour or alignment? What deep conceptual or inheritance 
problem was overcome in order to manage equal column widths on every row? why 
can that conceptual or inheritance problem not be solved for other attributes?

But what if there is a conflict? What if the row prescribes attributes that 
conflict with the column attributes?

I (and I suspect many others who have contributed to this topic) don't care. If 
the inheritance rules are stupid or awkward or unpredictable, I don't care. If 
one user agent does it one way, and another does it another, I don't care. 
Because at the end of the day, if I prescribe row properties that conflict with 
column properties, then it lies within my power to stop doing so.
(In reply to comment #178)
> The whole of CSS involves cascading through multiple parents - whole ancestral 

Elements never have multiple parents.  They may have multiple ancestors, but
never multiple parents.  And CSS inheritance only deals with the parent.  Yes,
the parent may in turn inherit from its parent, but CSS inheritance is easy to
define because it's only concerned with the parent.
In reply to comment #179:
We shouldn't try redefining the problem just in order to save implementation work.

Yes, in general CSS inheritance only depends on the parent element.  But why
can't there be a special case for tables with COL elements?
(In reply to comment #180)
> Yes, in general CSS inheritance only depends on the parent element.  But why
> can't there be a special case for tables with COL elements?

because nobody has explained how that special case would work
(In reply to comment #181)
> (In reply to comment #180)
> > Yes, in general CSS inheritance only depends on the parent element.  But why
> > can't there be a special case for tables with COL elements?
> because nobody has explained how that special case would work

It should work the same way that width and other COL attributes work already 
today.

What's the difficulty?!
> What's the difficulty?!

Read comment 162 carefully. Not a single CSS specialist/guru has solved that
problem yet.
(In reply to comment #178)
In case of conflicting attributes the best thing is to do ...nothing, i mean
let's use the default setting.
*** Bug 247748 has been marked as a duplicate of this bug. ***
Rather than having a special case of multiple-inheritance, is it not possible to define an ancestor-only 
direct hierarchy for application through CSS that does not necessarily match the DOM?

While the DOM hierarchy may be:
<table>
   <colgroup>
      <col />
   </colgroup>
   <tbody>
      <tr>
         <td> ... </td>
      </tr>
   </tbody>
</table>

would it not be possible to keep a modified DOM tree for CSS purposes that looks like:

<table>
   <tbody>
      <tr>
         <colgroup>
            <col>
               <td> ... </td>
            </col>
         </colgroup>
      </tr>
   </tbody>
</table>

Is this the terrible performance hit that's being described, the need to watch for changes to the DOM 
tree and replicate it (with changes) for a separate CSS tree?
Mmh. The CSS3 selector spec
(http://www.w3.org/TR/css3-selectors/#nth-child-pseudo) contains the following
example:

  tr:nth-child(2n) /* represents every even row of a HTML table */

which I assume could as well have been

  td:nth-child(5) /* represents every 5th column cell of a HTML table */

which AFAIU would provide (almost) exactly what COL does.

So my question is: Don't css-selectors 'break' the style cascade in the same way
a COL does?

And to reiterate an unanswered question: What is so special about the width
property of a COL as compared to its align property?
> So my question is: Don't css-selectors 'break' the style cascade in the same
> way a COL does?

No, because we can calculate which element is the fifth child of its parent
before we do layout: all you have to do is look at the DOM tree and count the
prior siblings.

> And to reiterate an unanswered question: What is so special about the width
> property of a COL as compared to its align property?

The width property doesn't get applied to the cell at all. It only affects the
cell because when we're actually calculating the layout, we do a width
calculation across the whole column, and both the cell and column widths get
accounted for during that stage. The align property needs to be *applied* to the
cell in order to affect its content, and styles only get applied to the cell
before layout -- before we know which cell is in which column. Similar logic
applies to background: the background doesn't get applied to the cell, it's a
box that gets painted *underneath* /all/ the cells. You can see this by setting
an image background on the column and then telling the cells to be transparent:
the image background will show through the transparent cell background as one
long picture that spans the cells.
What sort of algorithm is it which "applies the style"? It seems quite trivial 
in a depth-first traversal of the document tree to count column numbers 
without undue overhead.
(In reply to comment #188)
> > So my question is: Don't css-selectors 'break' the style cascade in the 
same
> > way a COL does?
> No, because we can calculate which element is the fifth child of its parent
> before we do layout: all you have to do is look at the DOM tree and count the
> prior siblings.

Well, the problem why COL stylea re not applied to a cell seems to be because 
a cell is not a descendant of that COL and it's not easy (or possible) to 
apply a style that's not inherited. But a 5th cell also looks at more than its 
parent when calculating its style, now why exactly is looking at a column more 
difficult than looking at how many child nodes does a cell's parent have? Both 
involve traversing the DOM tree up AND down (to a parent and down to each 
child for n-th selector, to a table parent and then down to n-th COL for a COL 
style).
Does this whole discussion sidestep display: table-column/table-column-group?
The suggestion that this is merely a deprecated HTML hack seems to ignore other
elements styled as table columns. Using td:nth-child(n) is not going to work for
rows that contain cells that span columns.

Would it be possible to treat the COL/COLGROUP alignment info as if it were an
attribute (array) of the TABLE itself? This way, inheritance would work a little
more consistently.
The fifth child of a TR may not be the fifth row if there are colspan or
rowspan elements prior.

But thanks, Stefan Moebius, for suggesting a workaround.  If I can
get a test case working demonstrating the workaround, would that be
grounds for dropping this bug's severity to "minor"?
"Row" in my last comment should read "column".

And no, Stefan's suggested workaround doesn't work because Gecko doesn't yet
recognize :nth-child (bug 75375; target: Future; no new patch since Q2 2001).
*** Bug 251069 has been marked as a duplicate of this bug. ***
*** Bug 252751 has been marked as a duplicate of this bug. ***
I hate to butt-in but isn't this fixed via CSS?

-R
> I hate to butt-in but isn't this fixed via CSS?

No, it isn't.  You can give the second cell in each row a class of "itemcost" or
some such, but you begin pushing back the HTML/CSS boundary of good-design. 
Being able to simply say that the second column is of a class would be clearer,
shorter, and a better separation of content and display.
I've seen sites use a workaround involving adjacent and first-child selectors
of CSS2.  According to a page on DevEdge, these selectors work in Mozilla, in
recent Opera, and in IE for Mac but not in IE for Windows.  You can use it too
until this bug gets FIXED.

Does this CSS2 workaround demote the bug to minor?
That "workaround" has the same problems as the n-th child "workaround."  i.e.
comment 151 and your own comment 152 still apply: spans will mess up the
intended rendering.
Btw, Opera supports this, too. I'm wondering how it does it (similar to the way
MS IE does ?)
*** Bug 256781 has been marked as a duplicate of this bug. ***
Why don't use the way described in comment #186 ?
*** Bug 259628 has been marked as a duplicate of this bug. ***
*** Bug 261350 has been marked as a duplicate of this bug. ***
*** Bug 262232 has been marked as a duplicate of this bug. ***
*** Bug 265838 has been marked as a duplicate of this bug. ***
Please forgive me for butting in, but I just joined Bugzilla and this quirk has
been aggravating me for a long time.  I have read all of the comments on this
bug, and fully understand the issues involved, originating with the CSS single
inheritance model and exacerbated by the lack of clarity in the CSS
specifications about how this particular case should be handled.  With respect
to what should be done, I wholeheartedly agree with the sentiments expressed in
comment #100 (and elsewhere):
> Regarding document structure, I think (X)HTML should trump CSS2
and
> I could live with an exception for (X)HTML, but not just for alignment. It
> should be for every CSS1(2?) property that applies to all elements and that
> inherits, unless there are some properties that should not be included for
> specific reasons.
Styles defined on COLs and COLGROUPs should affect the table cells in those
columns.  ALL appropriate (inheritable) styles, be they approved in CSS2 17.3
(like 'border', 'background', 'width', and 'visibility') or not (like
'text-align', 'font', 'z-index', even the aural properties and preferably also
'display:none').  With respect to tables, CSS2 6.1.1 and 6.2 are an incorrect
adaptation of document structure.  CSS3's ':nth-child' psuedo class is an
inadequate workaround, because of cells that span multiple columns.  But common
sense (and HTML4) dictates that CSS2 and CSS3 must be overridden here; tables
are two dimensional structures and table cells are contained by both rows and
columns.  IE understands this and Mozilla should too.  This way, we honor the
intended purpose of COLs and COLGROUPs while still separating content (HTML
elements) from style (CSS rules).

Once you decide that HTML4 should trump CSS structure but not CSS rules, then
the issue becomes how to apply the update in a logical, efficient, and minimally
changed manner.  The idea presented in comment #186 is to modify the DOM tree
for applying CSS rules (in other words, to create a pseudo-tree for TABLEs):
> <table>
>    <tbody>
>       <tr>
>          <colgroup>
>             <col>
>                <td> ... </td>
>             </col>
>          </colgroup>
>       </tr>
>    </tbody>
> </table>
This would work, but it involves a non-trivial change on every table and breaks
the symmetry between DOM structure and CSS ancestry.

I vote for the method suggested in comment #175 and comment #191, that is,
treating COLs and COLGROUPs more as attributes of TABLEs than as independent
elements.
comment #175:
> The difficulty seems to stem from the desire to have styles on a table cell
> inherited from a col tag that is not an ancestor of the cell in the document
> object tree.  Is it at all possible to make the col tag behave less like a
> separate element and more like an attribute of the parent table element that
> contains it?  If the table somehow stored the styles defined on its col tags,
> then the cells in that table could inherit from the table tag since it is a
> direct ancestor.  Also, that would allow inheritence to work in the expected
> order: table, col, tbody, tr, td.  Any thoughts on that?
comment #191:
> Would it be possible to treat the COL/COLGROUP alignment info as if it were an
> attribute (array) of the TABLE itself? This way, inheritance would work a little
> more consistently.
The inability of COLGROUPs to contain anything but COLs and the inability of
COLs to contain anything at all lend credibility to treating them as attributes
of TABLEs... indeed, this seems to be their purpose.  Programmatically, it
doesn't seem like this change would affect very much.  It would probably be the
most efficient change in terms of processor cycles, and would only take up more
memory where more would be needed anyway (when COLGROUPs and/or COLs are
specified).  It honors the intent of both HTML4 and CSS2, and would even work
for the CSS 'table-column' and 'table-column-group' display properties.

Well, I think my proposal is finished.  I am amazed at the longevity of this
bug, and hope that I can help resolve it.
(In reply to comment #207)
> been aggravating me for a long time.  I have read all of the comments on this
> bug, and fully understand the issues involved, originating with the CSS single
> inheritance model and exacerbated by the lack of clarity in the CSS
> specifications about how this particular case should be handled.  With respect

If you think there's any lack of clarity in the CSS specifications, then you
don't fully understand the issues involved.
(lack of clarity on this issue, that is)
I think Richard Gibson's proposal should be implemented as it sounds plausible
to me.  David Baron, could you please explain specifically why his proposal is
wrong?
The key problem is here:

(In reply to comment #207)
> I vote for the method suggested in comment #175 and comment #191, that is,
> treating COLs and COLGROUPs more as attributes of TABLEs than as independent
> elements.

This would mean, unless I'm misunderstanding what you propose, that any styles
associated with TR, THEAD, TBODY, and TFOOT would override those on COL and
COLGROUP, which is not what the HTML spec says should happen.
Note that applying stylistic attributes on inner table elements to the cell
(rather than acting as though they were attached to the the table) doesn't have
these problems.  Then again, I proposed that in comment 97 - comment 98 -
comment 99.
Whiteboard: SEE COMMENT 162 | need to contact the WG for clarification [HTML4-11.3.2] → READ COMMENT 131 BEFORE COMMENTING | need to contact the WG for clarification [HTML4-11.3.2]
I am part of this thread because I reported bug #265838 after finding an 
inconsistency with other browsers (IE and Opera). All this talk about how the 
rules of CSS inheritance should be interpretted is really becoming annoying, 
so let me add to the debate my throwing in my two penny's worth.

AFAIAW the rules of CSS inheritance are quite clear. You may specify style at 
various levels, and entries at lower levels override anything specified at a 
higher level. Thus within an HTML document style may be specified at any of 
the following levels:

(1) Browser defaults (Why are they all different? Why are they never 
documented?)
(2) External stylesheets (from CSS files).
(3) Internal stylesheets (between <style>..</style> tags).
(4) At the individual tag level.

It is therefore quite clear to me that anything specified within a COLGROUP 
tag overrides ANY previous specification, and it may only be overridden itself 
by other specifications within that particular table. Thus if I specify 
<colgroup valign="top"> I expect all relevant cells to be aligned at the top 
(regardless of any current setting for TD tags) UNLESS I specify something 
different on a particular TD tag.

Also bear in mind that the rules of CSS inheritance can only be strictly 
applied in XHTML documents where inline style is disallowed. As HTML documents 
can have a mixture of both then you must deal with that mixture and apply the 
style in the order in which it was specified, which may be from a mixture of 
stylesheet and tag info.

As a final point, regardless of how any individual *thinks* the rules should 
be interpretted, you should start by being consistent with other browsers.
(In reply to comment #212)
> This would mean, unless I'm misunderstanding what you propose, that any 
styles
> associated with TR, THEAD, TBODY, and TFOOT would override those on COL and
> COLGROUP, which is not what the HTML spec says should happen.

My reading of the HTML specification comes up with a totally opposite 
conclusion. If you go to http://www.w3.org/TR/html4/struct/tables.html#h-
11.2.4.4 and scroll down beyond the sample table you will read:

<quote>
We have set the value of the align attribute in the third column group 
to "center". All cells in every column in this group will inherit this value, 
but may override it.
</quote>

This is reinforced with the section entitled "Inheritance of alignment 
specifications" at http://www.w3.org/TR/html4/struct/tables.html#h-11.3.2.1 
which clearly states the following:

<quote>
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:

- An attribute set on an element within a cell's data (e.g., P). 
- An attribute set on a cell (TH and TD). 
- 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. 
- 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. 
- An attribute set on the table (TABLE). 
- The default attribute value. 
</quote>

Can you show me ANYWHERE in the HTML specification that says that the valign 
attribute on any COLGROUP or COL element is to be ignored?
The point is that the order of precedence for a bunch of other attributes (see
the paragraph just before the one you quoted) is the opposite regarding rows and
columns, and the solution you're strongly advocating is no easier to implement
than the one in comment 97 - comment 98 - comment 99 but leads to significantly
worse results.
(In reply to comment #217)
> The point is that the order of precedence for a bunch of other attributes 
(see
> the paragraph just before the one you quoted) is the opposite regarding rows 
and
> columns, and the solution you're strongly advocating is no easier to 
implement
> than the one in comment 97 - comment 98 - comment 99 but leads to 
significantly
> worse results.

I'm not concerned about how easy or not it is to implememnt. That's your job. 
The HTML specification clearly states the order of precedence, so I expect a 
standards-compliant browser to follow that order. If it does not, then it is 
not a standards-compliant browser and therefore unworthy of consideration by 
serious professionals who are constantly frustrated by all these different 
browsers which insist on 'doing their own thing'.
(In reply to comment #217)

I've been staying off the chilli for a couple of days and maybe I can say 
something more constructive.

No doubt the rules in the HTML or CSS specifications do give some kind of order 
of precedence. Maybe the specifications are ambiguous.

But many of the people who write web pages, and generate data tables on a 
terrifying scale, are actually very simple people who want to write simple code 
that doesn't exploit subtleties in the inheritance hierarchy. We keep our 
styles simple, specific and well-targeted. We ensure that our elements aren't 
larded with lots of overriding styles that might come out this way on one 
browser, and that way on another.

In particular, when producing a table, I (and other simple souls like me) are 
never ever going to play precedence games with the alignment of a column. And 
if we do, and things didn't go right, we would think that we had only ourselves 
to blame. If I have a column with four columns of text and one of numbers, I 
want the numbers right-aligned and the text left-aligned; and firing out td 
elements with alignment styles on each and every one of N rows times M columns 
just goes against our simple-minded principles, and we feel that (X)HTML plus 
CSS ought to be able to go one better.

We pea-brains do not understand why, when we do not want our browsers to 
distinguish complex inheritance rules that we ourselves cannot understand and 
frankly have better things to do, they cannot even understand basic 
instructions. Thus, when I have absolutely no styles whatever in my document 
except that I specify right-alignment for a numeric column via a col or 
colgroup element, I rate a browser that totally ignores my directives as 
inferior to one that tries to carry them out, however imperfectly.

So what I am suggesting is that if Mozilla did the smallest, meanest, measliest 
thing towards recognizing a col attribute and applying it, then even if it flew 
in the face of abstruse precedence rules, I would be content, because I can 
always construct my XHTML to avoid reliance on precedence rules.

And I think it's important not to lose sight of the purpose of (X)HTML, which 
is to present information. People like myself who are furiously polluting the 
web with data for (ugh!) ordinary consumers are actually trying to supply good-
looking accessible information first, and while we all no doubt like to follow 
standards and get one of those nice W3C tick-mark or check-box logos on our 
pages, that is a means to an end. We want something that works cleanly and well 
and is easily maintainable.

When the quest for perfect fulfilment of standards actually frustrates us who 
are trying to get them to work for us, it seems to me that there is something 
self-defeating going on. When, for example, I read (as I seem to do here) that 
it is reasonable of me to expect that I can control colour or background via a 
col element, but if I want alignment too then I am a simpleton who needs a 
smack on the head, I just feel we are losing touch with reality. It's like 
having a car with a steering-wheel that works the automatic indicators OK, but 
doesn't actually change the vehicle's direction. Stupid boy.

Finally, I prefer to work with something that tries to get it right, rather 
than something that doesn't try for fear of getting it wrong. The point of a 
browser is to be usable, isn't it, rather than to satisfy a small committee of 
gurus?

I apologize for my last stroppy antagonistic post. But I really do think that a 
change of priorities is called for.
None of the solutions proposed is easy to implement.  I really don't understand
why you're advocating doing it wrong when it's just as easy to do right.
(In reply to comment #220)
> None of the solutions proposed is easy to implement.  I really don't understand
> why you're advocating doing it wrong when it's just as easy to do right.

Ok, so for the "correct" solution here (which is apparently hard to implement),
if someone comes up with a patch to do it that way, will it get checked in? 
Comment 131 seems to indicate yes, but the general tone of the comments from
Mozilla devs on this bug seems to contradict that: I feel like any patch
submitted will either "touch too many parts of the code" or "be too
complicated", and be rejected on intangible, highly-subjective grounds.

As someone else has remarked, if this bug really isn't going to be fixed, please
mark it as WONTFIX so we can all stop wasting time here.  If a fix _is_ possible
and likely, then my question to all the people CCed on this bug is this: is
there someone capable and willing who can write a patch implementing the fix as
dbaron has described?  If so, speak up, and get to work.  It seems to me that
it's pretty clear how dbaron (et al.) want this bug fixed, and arguing isn't
going to do a thing about it, so if you're not capable and willing, there's no
reason for you to add another comment to this bug.  I've been watching this bug
for several years now, and I'm getting tired of most of the useless whining that
goes on here.  This is a bug report, people, not Slashdot.
I've got a few ideas, so I'm taking this. No guarantees, and, if you look at
4510, you'll see that I'm a slow coder. So don't expect anything anytime
soon--but I'm guessing no one else will take this even if I don't, so I'm
putting it on my list.

I actually did find comment 219 useful, there were a few helpful points there.
Suggestions about altering the DOM are not useful--we're definitely not going to
do that.
Assignee: core.layout.tables → fantasai.bugs
(In reply to comment #220)
> None of the solutions proposed is easy to implement.  I really don't 
understand
> why you're advocating doing it wrong when it's just as easy to do right.

No solution will be *right* until it follows the HTML specification 
on "Inheritance of alignment specifications" at 
http://www.w3.org/TR/html4/struct/tables.html#h-11.3.2.1 as I indicated in 
comment #216. As for ease of implementation THAT IS TOTALLY IRRELEVANT. If it 
were too easy then any moron could do it. I assume that you are above the 
level of moron?
here's some html that doesn't work in firefox 1.0PR (no news here)...
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<style type="text/css">
#tab {border-collapse:collapse;width:100%;}
#tab td {border:1px dotted black;}
.number {text-align:right;color:red;}
</style>
</head>
<body>
<table id="tab" cellspacing="0">
<col><col style="text-align:center;"><col class="number">
<tbody>
	<tr><td>a1</td><td>b1</td><td>c1</td></tr>
	<tr><td>a2</td><td>b2</td><td>c2</td></tr>
	<tr><td class="number">a3</td><td style="text-align: right;">b3</td><td
style="text-align: center;">c3</td></tr>
	<tr><td>a4</td><td>b4</td><td>c4</td></tr>
</tbody>
</table>
</body>
</html>

however if you change the DocType to Strict (<!DOCTYPE HTML PUBLIC "-//W3C//DTD
HTML 4.01 Strict//EN">) then IT WORKS PERFECTLY FINE just like in IE.

Does this mean that the problem has already been adressed and it's easy to patch
the 'Transitional'/default doctype?

- Mark

ps. as you can probably tell i have no idea about mozilla programming :)
(In reply to comment #224)
> here's some html that doesn't work in firefox 1.0PR (no news here)...
> however if you change the DocType to Strict (<!DOCTYPE HTML PUBLIC "-//W3C//DTD
> HTML 4.01 Strict//EN">) then IT WORKS PERFECTLY FINE just like in IE.
> 
I was unable to reproduce the test on Firefox 0.10.1 (win32).
I also tested the document as proper XHTML1.1 and XHTML1.0 Strict as well, and
still nothing.
Firefox ignored the <col /> declarations :(
(In reply to comment #225)
> (In reply to comment #224)
> > here's some html that doesn't work in firefox 1.0PR (no news here)...
> > however if you change the DocType to Strict (<!DOCTYPE HTML PUBLIC "-//W3C//DTD
> > HTML 4.01 Strict//EN">) then IT WORKS PERFECTLY FINE just like in IE.
> > 
> I was unable to reproduce the test on Firefox 0.10.1 (win32).
> I also tested the document as proper XHTML1.1 and XHTML1.0 Strict as well, and
> still nothing.
> Firefox ignored the <col /> declarations :(

i feel like a complete moron - it's actualy just background:red (not color:red)
that works in Strict but not in Transitional/default. The text-align and almost
all other attributes are still ignored. 
so to clarify, when using the above code with
".number {text-align:right;background:red;border:8px solid green;}" the only
difference between Transitional and Strict is that in Strict the third column
background is red.

And yes I am a complete IDIOT!!!
*** Bug 272182 has been marked as a duplicate of this bug. ***
Summary: column alignment resolution for <col align> not implemented (text-align, vertical-align styles on columns) [CASCADE] → implement inheritance of alignment attributes from columns (align, valign, char, charoff, (lang, dir)?)
*** Bug 274020 has been marked as a duplicate of this bug. ***
*** Bug 274666 has been marked as a duplicate of this bug. ***
*** Bug 278837 has been marked as a duplicate of this bug. ***
*** Bug 281812 has been marked as a duplicate of this bug. ***
*** Bug 283014 has been marked as a duplicate of this bug. ***
*** Bug 284283 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.1+
Comment on attachment 181768 [details]
Shows several problems with inheritance of attributes (incorrect testcase)

The CSS 'text-align' property isn't supposed to work this way.
Attachment #181768 - Attachment description: Shows several problems with inheritance of attributes → Shows several problems with inheritance of attributes (incorrect testcase)
Attachment #181768 - Attachment is obsolete: true
Independent of what the authors of the CSS2 standard were thinking here
(assuming they were thinking ...), there can be no doubt whatsoever about one
thing: it is an absolutely essential functional requirement for HTML authors to
have *some* way to set presentation attributes/properties (such as "center") on
a per-column basis. It is a minor technicality, whether this is done through the
HTML parser or the CSS engine, or using some other hack, as long as there is at
least *some* way.

It cannot be that the only way to get all cells in a single column of a table
centered is to add some HTML attribute to *each* *single* td element. This is
ridiculous! I do not know of any other self-respecting text-rendering language
that has no way of specifying per-colum alignment attributes for tables.

The cleanest thing, to me, would seem that *all* HTML attributes of <col> become
the default for all the <td> elements in that column. Then I can set a class=...
attribute in <col>, and the CSS engine can pick that up from the <td> element
and act on it. Remember: There is *no* other purpose at all for <col> than to
inherit attributes onto <td> (and <th>) elements. So obviously the only sensible
thing to do here is to inherit *all* attributes from <col> to <td>. Yes, I know
that SGML has no mechanism to specify that in a DTD, but who said that SGML/XML
is the end of all wisdom?

This is standardization at its worst ... :-(

Where standards fail, they deserve to be overridden by implementation practice.
This case very clearly calls for that.

This bug is *not* at all about support for an obsolete feature. This bug is
about Firefox failing an essential functional requirement by its users that is
not going away as long as mankind continues to tables.
I totally agree witn comment 236. Firefox and mozilla suite have implemented
many features only to be "more ie compatible". If this request is not an
standard, please implement just to be ie complatible.
Actually, IE has similar problems with COLGROUP tag as Firefox.
But this feature is in HTML 4.01 specification, so I think it should be
implemented in FF.
(In reply to comment #238)

Actually, I'm pretty sure IE does support it properly. I know I had trouble
trying to get it to work in both browsers. I was able to get it to work in IE in
the end, but not at all in FireFox.
No longer blocks: majorbugs
*** Bug 298456 has been marked as a duplicate of this bug. ***
Showing the text-align, vertical-align and color properties, originating from
rows and columns, via HTML style attributes and CSS rules.

I tested the HTML align and valign attributes as well, but in both Mozilla and
IE they had an identical effect to their corresponding CSS. These attributes
will be removed in XHTML 2.
Consistent with HTML4, columns take priority for horizontal alignment. Rows
take priority for vertical alignment, color, and presumably everything else as
well.

An explicit TR TD rule takes priority over inheritance from COL. An explicit
COL TD rule has no effect, and the CSS spec does not say that it should.
Column attributes have no effect whatsoever.
Malcolm's said he's taking a look at this, so assigning to him since I certainly
won't get to it for awhile.
Assignee: fantasai.bugs → malcolm.smith
*** Bug 301116 has been marked as a duplicate of this bug. ***
*** Bug 306650 has been marked as a duplicate of this bug. ***
Given the number of duplicates, it is pleasing that I searched before posting my
example of this bug: http://www.jdawiseman.com/papers/games/bugzilla-20050910.html

Presentational HTML is still used, but I don't understand the non-proximate
inheritance issues: good luck!
*** Bug 309253 has been marked as a duplicate of this bug. ***
Ok, so I know nothing about how Mozilla works, and I'm no expert on CSS, but I 
had a problem with this bug on a website I was working on, and I read all the 
comments, and had an idea:

Several people said something along the lines of:

"If there was a way to do this in CSS then we could translate the COL and 
COLGROUP tag attributes into the equivalent CSS style rules, and implement it 
that way"

"*BUT*" others replied,

"in CSS elements can only have a single parent, and the problem is that in 
HTML tables, the cells *effectively* have both TR and COL as 'parents', from 
the point of view of inheriting alignment, styles, etc."
[i.e. In CSS the document is a tree, but tables are meant to be rectangular 
grids, and so don't fit the tree model properly]


Then I saw mentioned the idea that CSS *selectors* could be used to select all 
cells in a column (or columns), and apply styles to them that way, by using 
the :nth-child() selector.

*BUT*

:nth-child won't really work, because cells can have their colspan attributes 
set, which screws up the exact correspondence between column number and child 
number.


So, here's my idea:


Why not implement a ":nth-column()" psuedo-class, that works just like :nth-
child, *EXCEPT* that for TD and TH elements it takes into account the COLSPAN 
values of their preceding siblings?  It couldn't possibly be hard to do that!

I think it would be really useful just on its own as an addition to CSS, for 
styling tables...
but the real point of my mentioning it here is that (I'm guessing) Mozilla 
could use it to implement COL and COLGROUP functionality, *** by internally 
translating the attributes on these tags into style rules using this new 
pseudo-selector ***, and assigning these rules an appropriate specificity.

As I said, I don't know anything about Mozilla internals, so I may be way off 
base here.  Also, it's not a perfect solution in any case, since

(a) The "align" attribute doesn't quite translate to the "text-align" style, 
or to any other CSS styles exactly, so the results could not quite be made to 
match the HTML4 specifications.

and

(b) As far as I can see this technique couldn't be used to deal with CLASS 
attributes on COL or COLGROUP tags (i.e. they should ideally work the same way 
as CLASS attributes on the TR tag or other ancestor tags).

Still, for all the people out there who are obviously desperate for some way 
to apply alignment and other styles to tables on a per-column basis, this 
solution would be MUCH better than doing nothing!

So, what do the gurus say - could this idea fly? or is it inherently flawed 
somehow?
Is it as easy to implement as it sounds?

At the very least, I hope I might have provoked some more thought on how to 
fix this problem!
It's not inherently flawed, and I've proposed it elsewhere
( http://lists.w3.org/Archives/Public/www-style/2005Jul/0121 ), but it wouldn't
actually fix this bug, so it belongs in another bug.
Malcom, I'm thinking of looking into this.  Have you made any progress, or do
you mind if I take it back?
Attached patch work in progress (obsolete) — Splinter Review
This patch basically works.  I still need to make a bunch of changes to other
files and discuss what methods should be public with jst, sicking, bz, etc. 
I'll pick it up once I land bug 309675.
Assignee: malcolm.smith → dbaron
Attachment #197116 - Attachment is obsolete: true
Status: NEW → ASSIGNED
FWIW, I only realized today that it could be anywhere near this simple, based on
a conversation I had with bz (I think) sometime in the past few days about
mapped attribute uniqueness.  I realized that I *could* use the attribute
mapping code, as long as I passed it a different mapping function.
Priority: -- → P2
Whiteboard: READ COMMENT 131 BEFORE COMMENTING | need to contact the WG for clarification [HTML4-11.3.2] → [patch]READ COMMENT 131 BEFORE COMMENTING | need to contact the WG for clarification [HTML4-11.3.2]
Target Milestone: Future → mozilla1.9alpha
Actually, that doesn't account for rowspan correctly; we really just have to
build a cellmap.
I was working for a while on a much more extensive fix. As expressed in comment
236 and comment 100, I wouldn't be satisfied with inheriting only the special
cases of align and valign.

Give me one week and I'll finish this off and post it here.
Well, as Ian and I have said a number of times before, I'm unlikely to be
satisfied with anything that does any more than those special cases unless the
standards are changed first to make it conformant.  I'd be interested to see
what you've done, but (a) it's worth discussing the design before doing too much
work and (b) there's nothing wrong with posting an incomplete patch (in fact,
it's strongly preferred).
(And note that I think changes in the standards to make such a thing conformant
are unlikely; there are better ways to add the same capabilities to CSS by
enhancing selectors rather than complicating the inheritance model.)
Malcolm, any news?  I'd be interested in seeing what it is you were doing before
continuing work on this.  It doesn't need to be complete.
Unfortunately my home computer is dead at the moment so my work has stalled.
From memory, the approach was this, though I've probably ommitted some important
things.

* In the TableCellFrame::setColIndex method, I set the style context of the cell
frame to a new context whose RuleNode is a subclass I call IntersectionRuleNode.
Objects of this class has a member variable indicating which column/row
intersection they refer to. I use a GetInstance method so that cells in
identical columns crossing identical rows get the same object.

* This RuleNode's GetStyle method traverses the rules of each context from table
to row, and from table to col. This way, anything specified on the col path
takes effect, unless it is overridden by anything on the row path.

* The handful of styles which the HTML spec says columns have priority for, are
special-cased.

Note that the context assigned to the cell is in the context tree, but its
associated RuleNode is not in the rule tree.
*** Bug 312087 has been marked as a duplicate of this bug. ***
*** Bug 318314 has been marked as a duplicate of this bug. ***
Flags: blocking1.9a1?
Changing the style context based on the type of frame created is broken -- the style data determine what type of frame to create, not the other way around.
(In reply to comment #264)
> Changing the style context based on the type of frame created is broken -- the
> style data determine what type of frame to create, not the other way around.

All sorts of rules like that will have to be broken if this bug is ever to be fixed. :)

Anyway, I've given up: my approach would have been completely alien to the existing design, and from your #258/259 it was unlikely to be accepted anyway.
*** Bug 330824 has been marked as a duplicate of this bug. ***
*** Bug 331760 has been marked as a duplicate of this bug. ***
It's the longest bug i'v seen...

Here is my idea:

can we introduce a new pseudo-class?

td:col(1) { text-align:right; }
td:col(2,3,4) { text-align:center; }
(In reply to comment #268)
> can we introduce a new pseudo-class?

We can, and I think we should, but it wouldn't fix this bug.  And I already said that in comment 251.  (And it was raised before in comment 250.)
I was excited when I saw the recent activity--then I read the comments.  Is someone waiting for W3C to declare TABLE et al. to be "deprecated"? Or maybe a new category is needed, e.g., "passé" ... 

I found Comment #162, and the linked blog, to be a good statement of the problem (at least if you don't know anything about Gecko internals), and #219 is a good description of the requirement.  Comment #250 suggests a good solution using CSS terms.  While it may offend some CSS purists, here is my take on a solution:

The key, of course, is this:  "If it's a table, map out its structure."  The problem is that if you do it too late, there's nothing left to inherit, while if  you do it too early, inheritance might change the structure.

This is a problem only if you define it too broadly.  In the following, feel free to substitute "element with display:table-column" for COL, etc.; this could work independently of tag names. 

1.  Since any COLGROUP or COL must appear before rows, the number of columns is determined first (if none defined, no problem!).  This can be performed before or after the CSS cascade, since columns aren't CSS parents.

2.  Implement an HTMLColumns collection, creating implied COL elements for COLGROUPs and spanned columns, or a range of columns for each COL.

3.  For each table cell, define a columnIndex attribute (and an entityReference to its column, if necessary for performance).  If it spans columns, its columnIndex is that of the first column it's in.

4.  "Perform inheritance of properties, inheriting magically from table columns if the column isn't inheriting its style itself." A choice exists: If there were no COL elements, there is no Columns collection and no columnIndex.  Conversely, the Columns collection is created from the implied columns, but inherits only the columns' widths, and only if the first row's cells can define widths (similar to the criteria for "table-layout: fixed").

(In trying to get similar results from FF and IE, I've noticed that FF is very shy about honoring "table-layout: fixed;" and this thread makes it very clear why...)

I'm sure I've missed something here, but this looks to me like an enhancement for inheritance.  If, at any point, an attribute of any cell is redefined so as to break this scheme, just exclude the cell from any column inheritance.  If it's preferable to restrict the CSS attributes to "easy" ones, just document it.
Flags: blocking1.9a1? → blocking1.9-
Corresponding Safari/WebKit bug is

http://bugzilla.opendarwin.org/show_bug.cgi?id=3241
*** Bug 354342 has been marked as a duplicate of this bug. ***
(In reply to comment #272)
Webkit is no longer hosted at opendarwin.org. The new URL is:

http://bugs.webkit.org/show_bug.cgi?id=3241
*** Bug 363829 has been marked as a duplicate of this bug. ***
I think, this will help to understand how to columns and rows should inherit properties in HTML tables: http://www.w3.org/html/wg/html5/#processing
Attached patch work in progressSplinter Review
Merged to trunk, with some comments indicating other needed changes that I didn't include last time.
Attachment #197125 - Attachment is obsolete: true
Note that attachment 286787 [details] [diff] [review] is basically the same as the two-year-old attachment 197125 [details] [diff] [review], just merged to the trunk, and is equally unready to be checked in.  I haven't done any work recently; I just thought I'd post the merged version (which I have since it's been in my tree all this time) due to bug 401823 (which contained the same patch, plus some errors, as far as I can tell).
Alias: column
I really wish the Firefox developers could read the standards. The HTML 4.01 specification clearly identifies in http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4 all the attributes which are supposed to be supported in <colgroup> and <col> elements which are:

id, class, style, title, lang, dir, align, valign, char, charoff, plus all the events at http://www.w3.org/TR/html401/sgml/dtd.html#events

This list is not affected by anything in the XHTML spec, or in any of the CSS specs, so it *IS* the standard, and therefore should be implemented in any browser which tries to pass itself off as "standards compliant".

The fact that this bug has been outstanding for so many years speaks volumes about the competence of the developers on this project. All they can do is whinge and whine and invent one stupid reason after another as to why it cannot be done. We, the users, do not care for such excuses. We expect a standards compliant browser to comply with the standards, and http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4 clearly identifies the attributes which are valid in the <COLGROUP> and <COL> elements.
  I had discovered this problem myself over three years ago and was pointed to this bug report by someone over in the MozzillaZine support forums. I realize that there are probably many things such as security vulnerabilities that are considered far more important and reading the various posts there seems to be a considerable difference of opinion among the developers about what the correct way is to fix this. But like any number of other people who've posted here I must say that it's exasperating that this has remained unfixed for such a long time. With FireFox V3 beta 4 just out isn't the time to fix this for the next release now?
It also missed the target milestone - we're at 1.9b5 and it's still not implemented, when the target was supposed to be 1.9a1

This 'bug' is at a DECADE old - MAYBE we could have the decade old HTML 4 and CSS2 polished off BEFORE you have people wasting time coding in specs that aren't even out of draft?
Target Milestone: mozilla1.9alpha1 → Future
Note that the main piece remaining to be done here is refactoring the cellmap code so that it can be used both by frames and by content.  We need to keep the frame cellmap (the one in layout/tables/) working exactly the way it does now, but add (for this code) a content cellmap, constructed lazily only when needed, that allows determining which *semantic* column a table cell is in (accounting for rowspan and colspan attributes in the markup -- note that in the future the frame cellmap may have to account for row-span and column-span CSS properties, but the content cellmap should not).  I suspect making it a template class may be the right way to do that, but I haven't looked into it in any detail.  They should use exactly the same algorithm for determining which row/column cells are in, but they should get the data about table structure (and, eventually, row and column spans) from different sources.

Once that code is written, the patch here could be fixed up and landed, and we could also implement semantic column selectors (such as the proposal in bug 371323).

That is a good bit of work, and I'd hoped that one of the (at least one, maybe more than one -- I don't have time to read all 288 comments right now to refresh my memory) people who'd claimed to have a patch to fix this would have implemented it, but nobody has that code, and writing it isn't at the top of my priority list.

(Just because something was published earlier doesn't mean it's actually more useful for Web authors.  That the spec in question is as poorly written and unclear as it is is perhaps a sign that it isn't useful, and that implementations aren't likely to do the same thing once it is implemented.  Given that Safari/WebKit doesn't do this either, we're not the only ones holding authors back from using the feature (which is more of a factor than the age of the specification).)

Just because it's not at the top of my list right now doesn't mean I'll never get back to working on it -- it's *on* my list.  But if somebody else wants to do the remaining piece, you're welcome to.


I'd also note that adding comments does NOT help -- it just makes this bug harder to understand.  For example, somebody coming along who wants to finish this is already pretty unlikely to find this comment explaining what's left to do, and the more comments that are added, the less likely they are to find it.
Just view the HTML file in Firefox. The problem will be obvious when you look at the file, but the file also contains a description of the problem.
I forgot to mention that I am trying to find out if my bug is the same as bug #915.
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
Priority: P2 → --
QA Contact: ian → layout.tables
Whiteboard: [patch]READ COMMENT 131 BEFORE COMMENTING | need to contact the WG for clarification [HTML4-11.3.2] → [patch]see comment 288 for work remaining to be done
Component: Layout: Tables → Style System (CSS)
QA Contact: layout.tables → style-system
With Bug 75375 fixed as of Firefox 3.1, there now is a fairly easy workaround to this bug, provided there are no table cells that span multiple columns or rows.

The CSS selector "tr > *:nth-child(k)" will allow one to style the cells of the kth column however you wish in a table that does not use rowspan or colspan.
However, there can be legitimate reasons for a cell to span more than one row or one column.  For example, see the table at <http://www.rossde.com/internet/Webdevelopers.html#developers>, which presents tabular data.  It has a table header cell that spans two columns and several cells in the left-most column that span more than one row.  
Flags: wanted1.9.1?
Priority: -- → P2
True, tho in cases such as you gave, the :nth-last-child() selector could be used, so long as the cells not being used at top or left for header information are all nonspan.  td:nth-of-type() also works if the top rows and left columns that may have cells with span use <th> for their cells.

More eccentric table designs still need this fixed, but the common cases will soon be handleable via this workaround.
for David Baron:
I understand your point of view but I would like to point that you are making a mistake (in my view):
First you say "Just because something was published earlier doesn't mean it's actually more useful for Web authors". But after that, you encourage people to stop writing here. Then how can you tell if the feature is needed by web authors if they dont write here asking for the feature to be implemented? Maybe there are tens of thousands or milions of web authors that would be happy to see it implemented in Firefox and in other browsers too.
Second: You say that messages added here prevent new comers to read your message. You can solve that very easy, on the top of the page there is a "Whiteboard: patch]see comment 288 for work remaining ...". You can put there the direct link to the #288 comment. If bugzilla platform doesnt allow that, well - then it should, so bugzilla should be improved.

to: Ernest Cline
Can you give me an example of using "td:nth-of-type()" please? I would like to be ready for when the feature will be implemented.
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1-
Anyone to mark bug #2212 as duplicate from this one ?

Dear Paul, i'll do a little "celebration" for this bug on my blog, as I was running around for near three days, and I need align=char for an application.
Is anyone currently working on this?
(In reply to comment #299)
> Is anyone currently working on this?

No; if someone were, they'd be encouraged to take the "Assigned to:" field.  Are you interested in working on it?
(In reply to comment #300)

> Are you interested in working on it?

Close enough, though I won't claim my chances of success are very high.  I'm intrigued and will certainly take a look, but wanted to make sure no one was sitting on a patch already.  Thanks.
Two notes:

  1. see comment 288
  2. note that my current (updated to mozilla-central) version of the work in progress patch is at http://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/tip/column-align-attribute , which gets updated whenever I merge (although unfortunately it's not served with a useful MIME type)
(In reply to comment #188)
> The align property needs to be *applied* to the
> cell in order to affect its content, and styles only get applied to the cell
> before layout -- before we know which cell is in which column...

I don't understand this statement. You know which cell is in which column based purely on the HTML structure and HTML attributes (colspan, etc.). Column membership is a function of the original HTML document structure, not layout. If I go and do something stupid with CSS like say columns should be displayed as flying monkeys, it doesn't matter at that point. It has no effect on the fact that <td> should inherit its HTML align attribute from the <col> to which it belongs.

Maybe this was in reference to the 4 CSS styles (17.3) which should be inherited via the column/column group "context". Again, I think this is still structural inheritance that doesn't require "layout" to assign cells to columns. The CSS spec even seems to imply structure when it says "in the source document cells are descendants of rows, never of columns".

So, what are the styles which need to be applied before a cell's column can be determined?
(In reply to comment #303)
> So, what are the styles which need to be applied before a cell's column can be
> determined?

None, for the column determination that needs to happen here.  All workable proposals for column-based styling choose what cells get the styles based on the column semantics in the markup.  If the author causes the display to be something else by using the 'display' property (or, in the future, the 'row-span' or 'column-span' properties), that's their problem.

That said, this has all been discussed before.  Adding comments to a bug that already has 300 comments is a really bad idea.  Please don't add any more unless you're actually contributing to fixing it.

Comment 288 describes the work remaining to be done to fix this bug.
I think this bug depends upon the implementation of align="char" (bug 2212), doesn't it?
No, it doesn't.  Implementing the inheritance mechanism is distinct from the set of attributes inherited; if we have to add one more to the set later once it's implemented, that's fine.
No longer depends on: character-alignment
It seems to me there's a lot of philosophical issues behind this long (10+ years) discussion. Mostly related to the way these things have been implemented.

But:
1. CSS cannot interfere with HTML as it's an optional layer atop HTML, especially when not explicitly used.
2. HTML clearly states how it'd work (http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4.2 and also http://www.w3.org/TR/html401/struct/tables.html#adef-char ).

HTML clearly defines column level alignment (as well as width, vertical alignment, id, class etc.) and that's it. This is why the <COL> and <COLGROUP> tags have been introduced. Partial implementations heavily limit those tags usefulness.
What I geuss is that CSS is in place even when you don't use/call/refer to it.
Also reported in ubuntu/launchpad: https://bugs.launchpad.net/bugs/353877
I still read "Style System (CSS)" as the affected component.
This problem is not in the CSS!
The problem is in the plain HTML rendering!
Accordingly to CSS, the <COL> tag doesn't have, for example, column level text alignment.
While HTML does (see comments #303 and #308 above).
Flags: blocking1.9.2?
Flags: wanted1.9.2?
Is there any update (from David Baron?) on this bug?
See comment 288.  (If there were anything new, I'd add it here.)
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
When applying a class to a <col> tag, it appears correctly when rendered in the browser, however if you print or even print preview the class is simply ignored.
Yep... At 11, I already knew how to multiplicate thanks to mathematic tables.

I'm finishing a statistical webapp, and having td colspan but no col makes us use class="" for each cell, increasing insanely HTML size. We hope one day we could recommend Firefox or even Prism because the work would be easier for everyone.

happy biiiiiiiiiiirthday #915
This feature is no longer present in HTML5, and has not been implemented in browsers other than IE, so I think this bug is now invalid.
Status: NEW → RESOLVED
Closed: 26 years ago14 years ago
Resolution: --- → INVALID
Keywords: helpwanted, qawanted
Hi David.

Okay for the depreciated attributes, but what for css equivalents, and text-align assigned to <colgroup> and <col> ?
I have business extranet that really need this for tabulated datas.
The bug on adding a CSS equivalent is bug 371323.
<colgroup> and <col> elements are exactly what they mean for : they are in the standards. I agree they are not easy to handle programmatically into a browser code, but (as webdev) we can define once in a time what each column do in this very one table. I have example with dozens of tables in a page, lot of them loaded and inserted by XHR, or dynamic adding/removing columns.

If we have to wait for a standardization of the -moz-*-column* , their adoption by other ones, the end of their prefixes...
And we'll have CSS hell to declare each table each column, instead to assign class in a col or colgroup, we would have to modify css without consistency for each table.

I maybe make lot of mistakes in my way to code, but I think we can't rid off this part of the HTML definitions. <Table>s are as necessary evils than money.
<colgroup> and <col> elements are exactly what they mean for : they are in the standards. I agree they are not easy to handle programmatically into a browser code, but (as webdev) we can define once in a time what each column do in this very one table. I have example with dozens of tables in a page, lot of them loaded and inserted by XHR, or dynamic adding/removing columns.

If we have to wait for a standardization of the -moz-*-column* , their adoption by other ones, the end of their prefixes...
And we'll have CSS hell to declare each table each column, instead to assign class in a col or colgroup, we would have to modify css without consistency for each table.

I maybe make lot of mistakes in my way to code, but I think we can't rid off this part of the HTML definitions. <Table>s are as necessary evils than money.
I too think that :-moz-nth-column() is a suboptimal alternative to styling col and colgroup elements directly…
About HTML5. Please check http://www.w3.org/html/wiki/Specifications . HTML5 is "a work in progress, [which] intends to replace HTML 3.2, HTML 4, and XHTML 1.x" . Anyone is free to work on those specs that could (and will) change before final publication. But it's hard to say "I won't bother about v4.01 because v5 is the new standard." v5-20100624 is just a draft. v4.01 IS the standard.

About bug invalidity. If you wait long enough, also "(void*) aPtr" can become an invalid C language expression, replaced by "c_static_cast( void*,aptr )". Nonetheless is could make sense to fix NOW a compile bug about "(void*) aPtr".

Does anyone in the stearing board still think that this bug is INVALID?
(In reply to comment #330)
> About HTML5. Please check http://www.w3.org/html/wiki/Specifications . HTML5 is
> "a work in progress, [which] intends to replace HTML 3.2, HTML 4, and XHTML
> 1.x" . Anyone is free to work on those specs that could (and will) change
> before final publication. But it's hard to say "I won't bother about v4.01
> because v5 is the new standard." v5-20100624 is just a draft. v4.01 IS the
> standard.
> 
> About bug invalidity. If you wait long enough, also "(void*) aPtr" can become
> an invalid C language expression, replaced by "c_static_cast( void*,aptr )".
> Nonetheless is could make sense to fix NOW a compile bug about "(void*) aPtr".
> 
> Does anyone in the stearing board still think that this bug is INVALID?

The goal of HTML5 is to standardize how all versions of HTML is parsed, based on what has already been implemented in the real world. The majority of the HTML5 standard is stable, and thus implementable. Very few browsers have implemented this portion of the old HTML4 standard, and it was likely decided that it was either too hard to implement or is really presentational (i.e. more suited for CSS). Based on that, I can understand why this bug was marked as INVALID.

However, I do believe that the idea behind this bug would still be useful—I would very much like to be able to style <col> and <colgroup>, including alignment, if necessary.
R.I.P. Mozilla bug 915.  We will miss you.

You were like a kindly old grandpa who was once loved.  Sadly, 12 years ago you were abandoned in an old peoples home.  There you sat day after day, hoping you would be brought out into the sun so the world could see your abilities.  See what you could do.  Be the hero the world needed.  But alas, that day never came and now your time has run out.

You will be missed by 189 watchers, but maybe not by your friend David B. ;)

Goodbye old friend.
That's a shame. How many cool but less useful features were brought into Firefox, and this little but useful and long awaited one get invalidated. Does not seem fair.
This is retarded. Opera also supports this clearly-defined portion of the HTML4 spec. The other two main browsers on the market run off the same rendering engine, and there's a long-standing open bug report for that engine (https://bugs.webkit.org/show_bug.cgi?id=3241) that is apparently waiting on action from Firefox. So it is an absolute cop-out to say "it's not in the HTML5 spec yet and the spec represents support in current browsers so it shouldn't be there because it's not widely supported", when you really mean to say "we don't support it, so we think it shouldn't be in the spec to begin with".

Shoving this feature off to be handled in CSS is NOT a good catch-all solution. It is a nightmare to do this if alignment needs to be changed on-the-fly via Javascript, or if the stylesheet for the page is inaccessible to a table independently created by a different process. Pushing the alignment down to an attribute on the cell is bulky, inefficient, and, all things considered, absolutely unnecessary, if we could rely on the col align feature in the HTML4 spec to begin with.

I hate to sound like a broken record, given the history in this thread, but COME ON. It's because of stupid little things like this that companies (mainly business-related web software) still require their users to use Internet Explorer for their pages - not necessarily because those companies are antiquated and averse to change, but because Internet Explorer JUST WORKS for this, and it's important to their users. Stop making excuses already and finish implementing this.
This is the most absurd bug resolution I've ever seen, especially when it comes to a standard, THE standard about web, HTML.

I still can't understand why this bug is closed, whereas much effort is put in over-the-hype features, still in discussion in the HTML5 *draft*, and that probably few developers will use in the near future.

What about intranets developed (for IE6) using these align attributes on the <col> & <colgroup>? The day the IT guys *finally* switch the users to FF, the layout won't behave the same under FF, and the least the developers could is... find an ugly CSS hack to work-around this unsupported standard feature. Is it what you people at Mozilla want? I never thought this kind of things would happen someday.
HTML5 is intended to be completely implemented before a draft is declared final.  I believe due to problems in the past where a final draft was discovered to be impractical during implementation.
Darxus - that doesn't mean that something won't be present in the final version, just because it isn't in it right now. And supporting HTML5 doesn't mean that Firefox can't support HTML4 too.

The HTML5 reasoning is an excuse here, plain and simple.
Scott:  Agreed.  I apologize for responding before catching up on this particular bug.
Scott and Darxus: that's the point.
As HTML5 is still draft, forgetting about HTML4 is a major mistake, IMHO.
And forgetting for 11+ years about an HTML4 core feature sounds like another mistake.
And finally, COL and COLGROUP make little sense without their properties.
So, please, MOZILLA dev group, embrace back this bug: unfinished HTML4 plus draft HTML5 sounds really a weak support to one of the most important standard in the world!
(In reply to comment #327)
> <colgroup> and <col> elements are exactly what they mean for : they are in the
> standards. I agree they are not easy to handle programmatically into a browser
> code, but (as webdev) we can define once in a time what each column do in this
> very one table. I have example with dozens of tables in a page, lot of them
> loaded and inserted by XHR, or dynamic adding/removing columns.
> 
> If we have to wait for a standardization of the -moz-*-column* , their adoption
> by other ones, the end of their prefixes...

... we'll be waiting forever, especially given the track record of IE in this regard.

> And we'll have CSS hell to declare each table each column, instead to assign
> class in a col or colgroup, we would have to modify css without consistency for
> each table.

The other problem I have with the whole thing is that there is NO alternative to the html align="char".  So, when I have a table of values with different significant figures, and I want them aligned at the decimal place, I have no way in either css or html to achieve this short of using a monospace font and adding non-breaking spaces to pad the right hand side!

Back to using pdf files for web pages, then...
(In reply to comment #330)
> About HTML5. Please check http://www.w3.org/html/wiki/Specifications . HTML5 is
> "a work in progress, [which] intends to replace HTML 3.2, HTML 4, and XHTML
> 1.x" . Anyone is free to work on those specs that could (and will) change
> before final publication. But it's hard to say "I won't bother about v4.01
> because v5 is the new standard." v5-20100624 is just a draft. v4.01 IS the
> standard.

This might be a little less funny if the relevant section of HTML4 was written by somebody who had a clue what they were talking about, but it clearly wasn't.  Inheriting the "style" attribute as a whole makes no sense, and would be a disaster for lots of Web pages if we actually implemented what it says.  This is like many things in HTML4; the specification is horribly written and a complete joke.

(In reply to comment #333)
> That's a shame. How many cool but less useful features were brought into
> Firefox, and this little but useful and long awaited one get invalidated. Does
> not seem fair.

This feature is far from little on the implementation side.  It may seem little from the authoring side, but implementing it requires a significant amount of code.  That's why it wasn't done.

(In reply to comment #334)
> After several working fixes and patches the whole thing suffers analysis
> paralysis until the spec itself ages and is deemed invalid. By a _draft_
> proposal, rather than by anything concrete.

The patches in this bug were still quite a ways from *working*.

(In reply to comment #336)
> I still can't understand why this bug is closed, whereas much effort is put in
> over-the-hype features, still in discussion in the HTML5 *draft*, and that
> probably few developers will use in the near future.

Given the amount of work needed to fix this bug (a significant part of which I did, actually) and the amount of benefit that would come from it, I still think the tradeoffs we made between this bug and fixing others were correct.

(In reply to comment #341)
> The other problem I have with the whole thing is that there is NO alternative
> to the html align="char".  So, when I have a table of values with different
> significant figures, and I want them aligned at the decimal place, I have no
> way in either css or html to achieve this short of using a monospace font and
> adding non-breaking spaces to pad the right hand side!

align="char" is bug 2212, not this bug


That said, I suppose I could still imagine taking a fix for this bug.  But I think it's probably more accurate to leave it closed.
Too bad that you don't want to solve this problem! Enough time and resources for implementation of modern CSS bells and whistles, but not for useful and long-time-awaited things...

http://www.grauw.nl/articles/css-faq.php#table-columns-properties
"Nevertheless, styling per column can be achieved by using td:nth-child(n). Problem with this are that this is 1. not compatible with column spans (although it could be, using [colspan=n] selectors in a verbose way), and 2. it cannot work on columns with different indexes but the same class. A selector like :nth-column() is not a solution, because it would depend on the properties set, creating circular dependencies. Also, such a selector does not address the second concern mentioned above."
David,

It sounds like you just said, "I've been doing a lot of the work on this problem so far; it's difficult and the spec is ambiguous, so I'm not working on this any more." That's fair, and I applaud your efforts so far. We know that you have done most of the work involved in trying to fix this, and I'm sure it will be very valuable in the future.

But there's a large difference between saying "I'm done working on this, someone else can finish it", and saying "This isn't actually a bug". The problem should have been reset to NEW and unassigned, instead of RESOLVED INVALID. It's still a very real problem (as indicated by today's firestorm of comments), with only workarounds available for developers who are currently affected.

Reopen the bug, please. It's much better to think that the fix is not coming yet, than to know that it's never coming at all. If I understand open-source development correctly, it's entirely possible that someone else may be able to fix this bug at a later time. If there's one thing that the age of this bug proves, it's that the Firefox users are willing to wait for this bugfix. :)
As with bug #178506, this bug is being closed because of what is convenient for the developers without regard for the needs of the users.  

This case is actually worse than bug #178506.  Here, the bug reflects non-compliance with the W3C HTML specification, the ONLY formal W3c HTML specification.  I thought a guiding principle of Mozilla was compliance with specifications.  I guess that applies only if it is not inconvenient to the developers.
A better example is bug 3875, the BASEFONT one. The reason for closing it was that it is an obscure element of HTML, deprecated in HTML 4.01. OK, but so is FONT. Let's try removing it's support from mozilla.org browsers. You see what I mean?

For a member of Mozilla Tech Evangelism team, closing of bug 3875 was a shocker. I had sent out hundreds of emails claiming we are standard compliant and therefore websites should be made more standard aware. After the sad demise of bug 3875 I could not claim that any more.

Sorry for this rant but the point is standard compliance is an important element of the image of mozilla.org. Something more important than the economy of including a patch.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
OK, I've reopened based on comment 344.
Status: REOPENED → NEW
Thank you for re-opening. A lot of feedback in so short a time must show that there's interest in this one, and I think the fact you took that on board and re-opened is to your credit.
Thank you for reopening, David! Much respect to you for doing so. :)
David, I also appreciate your action.
Unclear specs can be interpreted by developers. The smarter the developer, the better the interpretation.
An interpretation can be better than another one when it can make life easier without breaking everything.
The same happens with laws (which are rarely clear).
And maybe a smart interpretation in a technology leader like Mozilla can help writers to produce better specs in the future. Like final HTML5 specs! :-)
Could someone please update also the other bug metadata, like "Whiteboard" and "Keywords" (highrisk? testcase?)?
(In reply to comment #354)
> Happy 12th anniversary! Only one more year to go to become a teen!
Amazing that this bug has been pushed around for 12 years.

This will be a nice feature for finally specifying styling for a COLUMN of cells instead of each individual cell in a column, which is ironically is NOT the operation we're going for.

So I'm happy to see this being looked at.
Mmm. 
<COL align="char" char=".">, is it possible with CSS ? 

Anyway, it's not present in the HTML5 draft...
(In reply to comment #357)
> Mmm. 
> <COL align="char" char=".">, is it possible with CSS ?

No, it's not possible in CSS.
See http://www.w3.org/TR/2011/REC-CSS2-20110607/tables.html#columns

But http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.2.4.2 and http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#adef-align-TD and http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#adef-char suggest that plain simple HTML4 should suffice.
 
> Anyway, it's not present in the HTML5 draft...
HTML5-draft is just a ... ehm ... a draft.
It could completely vanish, be superseded by another draft or even be committed as a standard. Implementations relying on drafts are, IMHO, a huge waste of resources. And an ajoyable one, it looks to me.

The only current real standard is HTML4.01, though.
The support of this HTML 4.01 element is it planed ? Currently, except from changing the width or the background is not used much.
Accordingly to a number of earlier comments the Mozilla Design Board plans to leave the v4.01 support as it is now.
Unless someone will pick the issue up and solve it.
(I'm not part of that board).
Perhaps it's time to make a bounty to search and destroy this old bug.

Personnaly, I'm ok to put 15$ on it.

Anyone ?
$15 more from me.
Stop all this bounting (bug-hunting), please. :-)

Mozilla Firefox, Google Chrome, Konqueror, Rekonq, Safari and other similar browsers cannot handle simple HTML4 code.
They render HTML4 by always using implict CSS2 styiling. So CSS is in place even whrn you don't require it.
And thus, besides other nice "features", the <COL> tag is pretty useless. And will forever.

I hate this, but this is the way this crazy world is.

The option is to start a brand new browser project as it seems that a number of proposed patches has been rejected in the past...
(In reply to Uqbar from comment #365)
> Stop all this bounting (bug-hunting), please. :-)

Actually, comment 363 and comment 364 are the most constructive comments since comment 280.

€ 15,- from me.
I agree, Gecko should support column align via both HTML and CSS but now it haven't support at all. 
$15 more form me.
I really need vertical align by a character, because that is the only reason some companies uses IE + Excel in the intranet.

I put € 15.
I'm ttempted to pay a bounty to keep the bug in place. Over the years, it's felt like an old and familiar friend. I feel part of an exclusive club, defending bugdom and keeping the world safe from the boring conformity of fully working software.
(In reply to Xavier Mouton-Dubosc from comment #368)
> I really need vertical align by a character, because that is the only reason
> some companies uses IE + Excel in the intranet.

Well, the <COL> group makes a lot of sense to tabular data presentation anyway.
And it seems that it doesn't make any sense without it being fully implemented.

But guys, read the previous (very old) comments. It seems there's been a number of unsuccessful fix attempts in the past.
The HTML 4.01 and the CSS2 are conflicting (shame on the standardisation board) and the developers of all opensource brosers decided to go the same way: CSS2 everywhere. There's no will at all to implement the <COL> stuff as per the standard.
Joking aside, since WebKit is also waiting on Mozilla to take action on this fix, has anyone thought of contacting Opera and asking how they implemented it? They seem to be a leader in CSS compliance and have somehow created an implementation that follows HTML 4.01 without seriously compromising their CSS compliance. Who knows, they may be sympathetic to Mozilla's plight here (seeing as how this bug is so infamous by now), and may be willing to help out.

I say it's worth a shot, but obviously I don't have the kind of connections necessary to pull it off. :) David [Baron]?
And it seems the *align and other useful attributes were removed in HTML5 (http://dev.w3.org/html5/spec/Overview.html#the-col-element) to fix this conflict.
So a new HTML4-only browser is not a real option.
Scott, even if the Opera devs would through their hints in, do you know what'd the Mozilla devs answer?
It's already here, at Comment 324: we don't mind any more.
Uqbar - but Comment 324 was effectively negated by Comment 347, where this bug was reopened. I think I had something to do with that, but regardless, I'm just trying to be helpful here at this late stage of the game.

aceman - you do have a valid point. I'm definitely not willing to try myself to persuade the W3C to re-include align/valign/etc. in the HTML5 spec, and I don't know what debates have taken place within the working group on this topic, but think of it this way: if HTML5 is supposed to be a spec based on the current support of HTML5 in modern browsers, don't you think it could possibly change their mind if a real implementation was made by Mozilla and then followed by WebKit? That would mean support in all 5 of the major modern browsers, and then maybe there would be a stronger reason to reinclude it in HTML5. As has been pointed out here numerous times, <col> is effectively useless without align, and there is no alternative CSS approach that could possibly be as useful as the align attribute from HTML4.

I think it's still worth a shot.
I think <col> would also be useful to DRY CSS: cells in a column usually share many of their presentation properties, so this would avoid having the same CSS class[es] for every cell in the column.
Currently, "col" is useful only for background-color. Other than that and accessibily, I do not see.
I'd say that besides background-color, common cases are also font-*, color, padding, maybe even border.
You should discuss that here: http://www.w3.org/TR/2011/WD-html5-20110525/
(In reply to Scott Trenda from comment #371)
> Joking aside, since WebKit is also waiting on Mozilla to take action on this
> fix, has anyone thought of contacting Opera and asking how they implemented
> it? They seem to be a leader in CSS compliance and have somehow created an
> implementation that follows HTML 4.01 without seriously compromising their
> CSS compliance. Who knows, they may be sympathetic to Mozilla's plight here
> (seeing as how this bug is so infamous by now), and may be willing to help
> out.
> 
> I say it's worth a shot, but obviously I don't have the kind of connections
> necessary to pull it off. :) David [Baron]?

This isn't useful.  comment 288 describes exactly the work that remains to be done.  However, I'm more interested in doing that work in order to support the semantic column selectors in the selectors4 draft (in bug 371323) than to support the deprecated presentational attributes requested in this bug.
David, you should know by now that "deprecated presentational attributes requested" are fighting words in the context of this thread, but I'd like to discuss bug 371323 that you mentioned, instead.

I understand that as a volunteer contributor to an open-source project, the type of work that you are interested in doing does affect what makes it into the end product. On that note, I read the spec in the proposed selectors4 draft for :column(). I'd like to encourage you to pursue that implementation. I think that doing so will help both of us. It seems to be defined well enough from a CSS perspective to let you write it in a way that is compatible with the rest of your CSS engine. Once you have a :-moz-column() pseudo-class selector in place, couldn't you just add this set of rules to the internal Mozilla default stylesheet?

:-moz-column(col[align="left"     ]) { text-align: left   ; }
:-moz-column(col[align="center"   ]) { text-align: center ; }
:-moz-column(col[align="right"    ]) { text-align: right  ; }
:-moz-column(col[align="justify"  ]) { text-align: justify; }
:-moz-column(col[valign="top"     ]) { vertical-align: top     ; }
:-moz-column(col[valign="middle"  ]) { vertical-align: middle  ; }
:-moz-column(col[valign="bottom"  ]) { vertical-align: bottom  ; }
:-moz-column(col[valign="baseline"]) { vertical-align: baseline; }

Similar rules could be added for align/valign in colgroups:
:-moz-column(colgroup[align="left"] > col) { text-align: left; }

The downsides I see with this approach:
- it wouldn't cover align="char" and charoff
- I don't know if it'd be possible to handle cols with span defined
- assigning styles directly to the <col> element (e.g. col.style.textAlign = "center") wouldn't update the style

The upsides to this approach:
- it'd probably be good enough for most of the people in this thread
- it would be fairly harmless to add at that point (via the default stylesheet)
- it would finally bring an end to 13 years of fighting over this damn bug.

So please, godspeed on bug 371323. :)
(In reply to Scott Trenda from comment #374)
> I don't know what debates have taken place within the working group on
> this topic

All presentational features, such as <font>, align="", etc, were dropped in the new HTML standard, because they have been deprecated for over a decade and there's really no longer any reason for anyone to be using them in new documents. These features are now completely obsolete and it is non-conforming (invalid) to use them in HTML documents. I would not expect this to change even if browsers added support for this feature.

If you feel the need to discuss this decision, please do not do so on this bug (you can e-mail me directly if necessary to avoid posting here).
Great! So what were the *semantic* elements used to distinguish a simple text value from numeric, date, or other values again?
Apologies for any excessive snark in that last reply (and two volleys of bugspam), but there is a complete lack of semantic distinction to graduate to in order to meet reasonable presentational needs.

There may be a strong argument for a 'tn' (table numeric value) element in HTML5 for bare minimum numeric tabular data markup support (and consequential CSS alignment), even ignoring any need to align decimal characters or otherwise homogenize/improve the display of dissimilar/unsatisfactory numeric formats (like adding a printf-style format specifier to the col element). Allowing tr to directly contain elements like 'time' in HTML5 would be another practical solution. However, nothing like that exists today, or to my knowledge has even been fully proposed.
(In reply to Scott Trenda from comment #371)
> Joking aside,

No joke, my money is real
In reply to Brian, even if we had a <tn> element, it wouldn't help to align texts to a "pivot" character. align:"char" is/was a very interesting way in html/css to do the job.

And I even seen it used in a copy/paste from OpenOffice to a browser (in a html attribute)...

Every other "solution" is only... painful

As for col/colgroup to really group cols. And don't talk again about :nth in css, it simply fail stupidly where you have to colspan/rowspan
(In reply to Scott Trenda from comment #380)
> Once you have a
> :-moz-column() pseudo-class selector in place, couldn't you just add this
> set of rules to the internal Mozilla default stylesheet?

Scott, your remark seems to me to make a lot of sense. Pretty much.
Maybe not in the solution itself, but rather in its philosophy.
I mean, the missing parts you mentioned would need some extra programmatic approach, like linking (default, built-in) Javascript procedures to default CSS.

A few facts.
1. HTML4 documents and applications won't vanish overnight once HTML5 will be a standard. A better support to HTML4 will make the web a better place.

2. W3C standards have proven not to be bullet proof (among the most recent cases: http://it.slashdot.org/story/11/10/22/0310230/xml-encryption-broken-need-to-fix-w3c-standard).

3. Smart interpretation (of standards) and implementation (of browsers) in the mid- long-term are better than strict ones.

(In reply to Scott Trenda from comment #380)
> So please, godspeed on bug 371323. :)

Yes, pleeeease!
Alias: col-align-inherit
This bug is old enough to drive a car.

Given that no progress has occurred in years, given that the property is officially obsolete, and given that WebKit/Blink renders the testcases identically to Gecko, I think it's time to be honest and resolve this WONTFIX.
I think everyone will concede to honesty here.
But, for the sake of honesty, everyone should concede that if you wait long enough, any bug will end up this very way. It's called the ostrich philophy.

Comment 17 (18 months later) was the technical key point for a fix and a quick one.
Comment 324 (12 years later) has been the political key point not to fix it.

I would bet that HTML5 doesn't have this feature because "no browser has ever had it" in the 16 years (well, I don't consider IE a real web browser). But I could be badly wwong.
So long, bug no.915!
When a bug report describes an actual discrepancy (not an RFE), closing it merely because it has not yet been fixed is a fantasy.  Even if the bug is difficult to fix, something is definitely wrong with the code.  As long as the code is discrepant, the bug report should thus remain open.
I can see closing the parts relating to character alignment as WONTFIX.  Those are explicitly stated as optional in the HTML4 spec and they would definitely impact performance, especially when the engine has to calculate the character offset.  The other attributes only require column inheritance of properties.  That was fairly simple in the pre-CSS pre-DOM days as the user agent could know which column a cell was in and always would be.  The former is still true and I doubt that there would be many cases where these attributes would be used where DOM manipulations would be done.
While the alignment attributes are gone now, the style attribute remains.

Are we using "honesty" as a euphamism for avoiding difficult functionality?

Is there a reasonable solution to aligning by column, rather than cell-by-cell, other than this one or the CSS :numeric selector proposal at https://www.w3.org/Bugs/Public/show_bug.cgi?id=18026 ?
All this story makes no sense, in the end.
According to the previous comments above:

Those who wrote the standard had no clue about what was being defined. So no correction (aka 4.02?) to the HTML standard has been proposed/discussed/done in 15 years.

Implementing and reimplementing for years interim unstable specs has been considered more important than fixing the current stuff.

If anything is too hard to fix, than shame on application developers, each of them, to find a suitable workaround in their software.

Sounds like we are at Microsoft or IBM more than the Mozilla Foundation.
Despite the motto "We’re building a better Internet" (https://www.mozilla.org/en-US/mission/) and the manifesto "08 Transparent community-based processes promote participation, accountability and trust."
I need to be wrong and/or misinterpreting all these words. Shame on me.
Please close this bug with whatever tag you want. It won't matter anyway.

I only hope that challenging someone's choices is not interpreted as impolite, rude or unkind.
I hate to accept technical stuff blindly and with no factual justification.
(In reply to Brian Lalonde from comment #392)
> Is there a reasonable solution to aligning by column, rather than
> cell-by-cell, other than this one or the CSS :numeric selector proposal at
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18026 ?

Please see comment 288 and comment 379 (which, really, you should have read before adding comments here; if people don't read the bug before commenting, it will grow too big for anybody deciding what to do about the bug to read the comments).
(In reply to David Baron [:dbaron] (UTC-7) from comment #394)
> Please see comment 288 and comment 379 (which, really, you should have read
> before adding comments here; if people don't read the bug before commenting,
> it will grow too big for anybody deciding what to do about the bug to read
> the comments).

I am familiar with this bug, as I've been following it for more than ten years. I don't see the point in calling out bugspam by adding further bugspam, and replies should really be more constructive than scolding. I'd say the ship has probably already sailed on the size of the comments here.

The problem with a style (CSS :-moz-nth-column()) solution (as mentioned in the W3 bug I linked to) to a content problem, is that:

  1. Content authors are less likely to have access to a site's stylesheet
     than to a site's markup.
  2. It's unmaintainable for separate, centralized stylesheets. Every table
     would need a class or id and changes to the number of columns for any
     table would require splitting it from the class or updating the site
     stylesheet's column styles for that id. What does the WYSIWYG or wiki
     or CMS process look like for this?
  3. Maintaining it closer to the table using inline styles or (perhaps
     eventually) scoped CSS doesn't really have any advantage over the
     align attribute approach, and may have significant disadvantage
     (such as having to update the individual page's style when table
     changes are made).

There's more in the 18026 ticket, although using col element alignment doesn't address much of the problem of using a columns physical position to determine it's appearance either, but in the current absence of a td:numeric selector, a pure markup solution can be important.
> Status: NEW
> Reported: 20 years ago

Perhaps it's time to close this one out?
(In reply to Ryan Hayle from comment #397)
> > Status: NEW
> > Reported: 20 years ago
> 
> Perhaps it's time to close this one out?

Funny you should say that now - just earlier this week I came across a 16-year old bug in Bugzilla, and thought, "I wonder how old 915 is by now". Personally I would be happy to just sit and let it age with its "NEW" status, as an internet relic of browser and spec history... but with the HTML5 spec officially deprecating these attributes (and HTML5 being old and stable enough for that decision to be less contentious among developers), closing this bug as WONTFIX does sound appropriate.
(In reply to Scott Trenda from comment #398)

> Personally I would be happy to just sit and let it age with its "NEW"
> status, as an internet relic of browser and spec history... but with the
> HTML5 spec officially deprecating these attributes (and HTML5 being old and
> stable enough for that decision to be less contentious among developers),
> closing this bug as WONTFIX does sound appropriate.

I’m completely with you on wanting to leave it open, but I think it does need some sort of resolution, if for no other reason than clarity.  I wish there was a status like OBSOLETE or NLR (No Longer Relevant) to indicate that it was closed not because a “fix” was found and rejected, or the original request was misguided, but because the original impetus was nullified by subsequent events.
I'm not sure why this would be considered either obsolete or NLR. Is there some new solution to column alignment other than decorating each cell or setting up fragile rules using distant selectors based on physical location?

No real updates on https://www.w3.org/Bugs/Public/show_bug.cgi?id=18026 for the HTML spec so far, so maybe I'm missing something.

(The updated password requirements here are *absurd*. Is money handled somewhere here now?)
HTML 4 and earlier have officially been superseded by HTML 5.  So although browsers continue to support HTML 3 and 4 (and most of my web pages are written for those specifications), it is clear that Mozilla is not going to spend time or money fixing the browser to support what they apparently believe to be an obsolete standard.  I think it's time to put this bug out of its misery.
Brian's link to the w3.org bug was interesting, but all modern browser now support nth-child.  I will just have to redo my web pages.  *sigh*
Agree with Wayne, and note that W3C spec dev is now done in github:
https://github.com/w3c/html/issues/ 

It is a while since bugzilla was used for HTML/CSS etc.

Previous versions of HTML (that include align attributes on col) are superseded, and the recent versions don't include align attributes on col:
https://www.w3.org/TR/html52/tabular-data.html#the-col-element

I beleive it is seen as a presentational, therefore CSS issue.

Which is a shame, this is the first bug I subscribed to in around 1998 ;-)
I guess it is safe to close it. It has been more than 20 years and it is unlikely we will spend time on it...
Status: NEW → RESOLVED
Closed: 14 years ago5 years ago
Resolution: --- → WONTFIX
(In reply to Wayne Pollock from comment #401)
> Brian's link to the w3.org bug was interesting, but all modern browser now
> support nth-child.  I will just have to redo my web pages.  *sigh*

As mentioned in that link, nth-child is not a solution, not due to lack of support though. There's a reason to one uses it.

Adding CSS somewhere, the style
(In reply to Wayne Pollock from comment #401)
> Brian's link to the w3.org bug was interesting, but all modern browser now
> support nth-child.  I will just have to redo my web pages.  *sigh*

As mentioned in that link, nth-child is not a solution, not due to lack of support though. There's a reason to one uses it.

Adding CSS somewhere, even when you can, to style a single table by column position (which can change as you author/update it), is unmaintainable at best.

Examine tables in the wild. It's all cell-by-cell attributes, either by CSS classes or alignment attributes. Think about how inefficient that is. All because no one takes this bug seriously.

(Almost impossible to add a comment to this bug in Firefox Mobile.)
You need to log in before you can comment on or make changes to this bug.