Bug 915 (col-align-inherit)

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

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
P4
normal
19 years ago
16 days ago

People

(Reporter: kipp, Unassigned)

Tracking

(Blocks: 2 bugs, 4 keywords)

Trunk
Future
css2, highrisk, html4, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.3a -
blocking1.9.2 -
wanted1.9.2 -
blocking1.9.1 -
wanted1.9.1 -
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(14 attachments, 4 obsolete attachments)

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
(Reporter)

Description

19 years ago
something about a missing colframe...

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 1

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → REOPENED

Updated

19 years ago
Resolution: FIXED → ---

Comment 2

19 years ago
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).

Comment 3

19 years ago
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.

Updated

19 years ago
Summary: this page triggered an assertion in the table code → column style resolution not yet implemented

Comment 4

19 years ago
changed summary to reflect the real problem.

see discussion summary at
http://warp/client/raptor/table_column_style_resolution.html

Updated

19 years ago
Assignee: buster → peterl
Status: REOPENED → NEW

Comment 5

19 years ago
*** Bug 1129 has been marked as a duplicate of this bug. ***
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M4 → M6

Updated

19 years ago
Target Milestone: M6 → M8
Comment hidden (obsolete)
Blocks: 7954
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.
Comment hidden (obsolete)
Comment hidden (obsolete)

Updated

18 years ago
Whiteboard: need to contact the WG for clarification

Comment 12

18 years ago
*** Bug 19040 has been marked as a duplicate of this bug. ***
Comment hidden (obsolete)

Updated

18 years ago
Target Milestone: M16 → M15
Comment hidden (obsolete)

Comment 15

18 years ago
*** Bug 24595 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Keywords: beta1, css1

Comment 16

18 years ago
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.

Comment 18

18 years ago
Putting on PDT- radar for beta 1.
Whiteboard: need to contact the WG for clarification → [PDT-]need to contact the WG for clarification

Comment 19

18 years ago
Created attachment 4900 [details]
a testcase extracted from bug 26376 (problem with height:100%)

Comment 20

18 years ago
*** Bug 23995 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
*** 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
Comment hidden (obsolete)

Updated

18 years ago
Blocks: 29055

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 24

18 years ago
*** 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

Comment 26

18 years ago
Created attachment 6578 [details]
Smaller testcase for COLGROUP inheritance (easier debugging)

Comment 27

18 years ago
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.

Comment 28

18 years ago
Moving off to M16 while we wait for clarification from the WG.
Target Milestone: M15 → M16

Comment 29

18 years ago
*** Bug 34814 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Keywords: nsbeta2
Whiteboard: [PDT-] still need to contact the WG for clarification → still need to contact the WG for clarification

Comment 30

18 years ago
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.

Comment 32

18 years ago
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?

Comment 34

18 years ago
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.

Comment 36

18 years ago
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?

Comment 37

18 years ago
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.
Created attachment 8248 [details]
Testcase demonstrating the MacIE 5 behavior
>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.
Created attachment 8249 [details]
New testcase

Comment 42

18 years ago
| 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.

Comment 43

18 years ago
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: beta1 → helpwanted
Priority: P2 → P3
Target Milestone: M16 → Future
Comment hidden (obsolete)
Comment hidden (obsolete)
*** Bug 38917 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Keywords: testcase

Updated

17 years ago
Blocks: 43178

Comment 47

17 years ago
*** Bug 43727 has been marked as a duplicate of this bug. ***
*** Bug 44981 has been marked as a duplicate of this bug. ***
Comment hidden (obsolete)
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]

Comment 63

17 years ago
*** 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: css1 → html4
Comment hidden (spam)

Updated

17 years ago
Blocks: 43997
Comment hidden (obsolete)

Updated

17 years ago
No longer blocks: 43997

Comment 67

17 years ago
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

Comment 71

17 years ago
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?

Comment 72

17 years ago
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.

Comment 74

17 years ago
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.

Comment 77

17 years ago
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. ***
Comment hidden (spam)
Blocks: 98694

Comment 81

16 years ago
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.

Updated

16 years ago
Blocks: 104166

Comment 82

16 years ago
Created attachment 54454 [details]
Testcase from HTML 4.01 specification

Comment 83

16 years ago
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.

Comment 85

16 years ago
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.

Comment 86

16 years ago
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. ***

Comment 89

16 years ago
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. ***

Comment 92

16 years ago
*** 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

Comment 94

16 years ago
not critical for mozilla1.0
Keywords: mozilla1.0 → mozilla1.0-

Comment 95

16 years ago
*** Bug 139569 has been marked as a duplicate of this bug. ***

Comment 96

16 years ago
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.

Comment 100

16 years ago
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.  

Comment 101

16 years ago
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

Comment 102

16 years ago
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.

Comment 104

16 years ago
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.  

Comment 105

16 years ago
*** Bug 145250 has been marked as a duplicate of this bug. ***

Comment 106

16 years ago
*** 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]

Updated

15 years ago
Blocks: 2068

Comment 107

15 years ago
*** Bug 168663 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Keywords: mozilla1.0-
*** Bug 176338 has been marked as a duplicate of this bug. ***

Comment 109

15 years ago
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.

Comment 110

15 years ago
I just visited one of my own pages (
http://futureboy.homeip.net/bjexec/hodds.exe ) and noticed that Mozilla has
recently started to render COLGROUP's 'hsides' and 'vsides' rules correctly.

The "Testcase from HTML 4.01 specification" attachment that I submitted above
works correctly now also.  There has obviously been some work done by someone at
least tangentially related to this problem.  In fact, my problems are finally
solved.  Thanks to whoever worked on this.

Comment 111

15 years ago
Rules (using collapsing borders) on row/col groups was fixed by bug 41262 more
than 8 months ago.

Comment 112

15 years 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. ***

Updated

15 years ago
Flags: blocking1.3a?
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (offtopic)

Updated

15 years ago
Blocks: 41368
Status: NEW → ASSIGNED
Comment hidden (obsolete)
*** Bug 193843 has been marked as a duplicate of this bug. ***
Comment hidden (offtopic)
'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).
Comment hidden (obsolete)
Created attachment 115425 [details]
Testcase for text-align

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)
Created attachment 115446 [details]
Testcase for comparing with IE6.0SP1

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.

Updated

15 years ago
Blocks: 163993
*** Bug 202998 has been marked as a duplicate of this bug. ***

Comment 127

15 years ago
IE also support align and style, set in "col"

Comment 128

15 years ago
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.

Comment 129

14 years ago
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."

Comment 130

14 years ago
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?

Comment 137

14 years ago
Created attachment 125172 [details]
testcase css vs html attributes

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]

Comment 142

14 years ago
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.

Comment 147

14 years ago
> ... 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.

Comment 149

14 years ago
> 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. ***

Comment 152

14 years ago
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.  
.

Comment 154

14 years ago
*** Bug 228895 has been marked as a duplicate of this bug. ***

Comment 155

14 years ago
*** Bug 229798 has been marked as a duplicate of this bug. ***
*** Bug 233052 has been marked as a duplicate of this bug. ***

Comment 157

14 years ago
*** Bug 235071 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Alias: column
Keywords: qawanted
QA Contact: madhur → ian

Comment 158

14 years ago
*** 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>)

Updated

14 years ago
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]

Comment 161

14 years ago
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]

Comment 163

14 years ago
(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)?

Comment 164

14 years ago
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...

Comment 165

14 years ago
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.

Comment 167

14 years ago
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.

Comment 169

14 years ago
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.

Comment 171

14 years ago
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.

Comment 172

13 years ago
*** Bug 244845 has been marked as a duplicate of this bug. ***
*** Bug 245939 has been marked as a duplicate of this bug. ***

Comment 174

13 years ago
*** Bug 246461 has been marked as a duplicate of this bug. ***

Comment 175

13 years ago
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 176

13 years ago
(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.

Comment 178

13 years ago
(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.

Comment 180

13 years ago
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

Comment 182

13 years ago
(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?!

Comment 183

13 years ago
> What's the difficulty?!

Read comment 162 carefully. Not a single CSS specialist/guru has solved that
problem yet.

Comment 184

13 years ago
(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.

Comment 185

13 years ago
*** Bug 247748 has been marked as a duplicate of this bug. ***

Comment 186

13 years ago
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?

Comment 187

13 years ago
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?

Comment 188

13 years ago
> 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.

Comment 189

13 years ago
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.

Comment 190

13 years ago
(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).

Comment 191

13 years ago
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.

Comment 192

13 years ago
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"?

Comment 193

13 years ago
"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).

Comment 194

13 years ago
*** Bug 251069 has been marked as a duplicate of this bug. ***

Comment 195

13 years ago
*** Bug 252751 has been marked as a duplicate of this bug. ***

Comment 196

13 years ago
I hate to butt-in but isn't this fixed via CSS?

-R

Comment 197

13 years ago
> 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.

Comment 198

13 years ago
Created attachment 156716 [details]
Workaround using CSS2 adjacent selectors

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?

Comment 199

13 years ago
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.

Comment 200

13 years ago
Btw, Opera supports this, too. I'm wondering how it does it (similar to the way
MS IE does ?)

Comment 201

13 years ago
*** Bug 256781 has been marked as a duplicate of this bug. ***

Comment 202

13 years ago
Why don't use the way described in comment #186 ?

Comment 203

13 years ago
*** Bug 259628 has been marked as a duplicate of this bug. ***

Comment 204

13 years ago
*** Bug 261350 has been marked as a duplicate of this bug. ***

Comment 205

13 years ago
*** Bug 262232 has been marked as a duplicate of this bug. ***

Comment 206

13 years ago
*** Bug 265838 has been marked as a duplicate of this bug. ***

Comment 207

13 years ago
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)
Comment hidden (abusive)

Comment 211

13 years ago
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]

Comment 214

13 years ago
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.
Comment hidden (offtopic)

Comment 216

13 years ago
(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.

Comment 218

13 years ago
(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'.

Comment 219

13 years ago
(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.

Comment 221

13 years ago
(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.

Comment 222

13 years ago
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

Comment 223

13 years ago
(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?

Comment 224

13 years ago
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 :)

Comment 225

13 years ago
(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 :(

Comment 226

13 years ago
(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. ***

Comment 229

13 years ago
*** Bug 274666 has been marked as a duplicate of this bug. ***

Comment 230

13 years ago
*** Bug 278837 has been marked as a duplicate of this bug. ***

Comment 231

13 years ago
*** Bug 281812 has been marked as a duplicate of this bug. ***
*** Bug 283014 has been marked as a duplicate of this bug. ***

Comment 233

13 years ago
*** Bug 284283 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking-aviary1.1+

Updated

13 years ago
Flags: blocking-aviary1.1+

Comment 234

13 years ago
Created attachment 181768 [details]
Shows several problems with inheritance of attributes (incorrect testcase)
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

Comment 236

12 years ago
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.

Comment 237

12 years ago
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.

Comment 238

12 years ago
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.

Comment 239

12 years ago
(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.

Updated

12 years ago
No longer blocks: 163993

Comment 240

12 years ago
Created attachment 185867 [details]
Testcase where table cell alignment comes from COLGROUP/COL tags only, no CSS.

Comment 241

12 years ago
*** Bug 298456 has been marked as a duplicate of this bug. ***

Comment 242

12 years ago
Created attachment 189438 [details]
Column and row styles conflicting in various ways

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.

Comment 243

12 years ago
Created attachment 189440 [details]
Appearance of previous attachment in IE

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.

Comment 244

12 years ago
Created attachment 189441 [details]
Appearance or previous attachment in Gecko/20050513

Column attributes have no effect whatsoever.

Comment 245

12 years ago
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. ***

Comment 250

12 years ago
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?
Created attachment 197116 [details] [diff] [review]
what I was thinking of (work in progress, doesn't compile)
Created attachment 197125 [details] [diff] [review]
work in progress

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.

Comment 257

12 years ago
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.

Comment 261

12 years ago
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.

Comment 262

12 years ago
*** Bug 312087 has been marked as a duplicate of this bug. ***

Comment 263

12 years ago
*** Bug 318314 has been marked as a duplicate of this bug. ***

Updated

12 years ago
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.

Comment 265

12 years ago
(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.

Comment 266

12 years ago
*** Bug 330824 has been marked as a duplicate of this bug. ***
*** Bug 331760 has been marked as a duplicate of this bug. ***

Comment 268

12 years ago
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.)
Comment hidden (offtopic)

Comment 271

11 years ago
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-

Comment 272

11 years ago
Corresponding Safari/WebKit bug is

http://bugzilla.opendarwin.org/show_bug.cgi?id=3241

Comment 273

11 years ago
*** Bug 354342 has been marked as a duplicate of this bug. ***

Comment 274

11 years ago
(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. ***
Duplicate of this bug: 366862
Blocks: 371323
Blocks: 98694

Comment 277

10 years ago
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
Duplicate of this bug: 401823
Created attachment 286787 [details] [diff] [review]
work in progress

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

Updated

10 years ago
Alias: column
Comment hidden (offtopic)

Updated

10 years ago
Duplicate of this bug: 412748

Updated

10 years ago
Duplicate of this bug: 414953

Comment 284

10 years ago
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.
Comment hidden (offtopic)

Comment 286

10 years ago
  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?

Comment 287

10 years ago
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

Comment 288

10 years ago
important
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.

Comment 289

9 years ago
Created attachment 318932 [details]
HTML file showing that Firefox does not honour <col valign="top"> 

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.

Comment 290

9 years ago
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

Comment 291

9 years ago
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.

Comment 292

9 years ago
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.  

Updated

9 years ago
Flags: wanted1.9.1?
Priority: -- → P2

Comment 293

9 years ago
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.

Comment 294

9 years ago
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-
Comment hidden (offtopic)
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.
Bug 2212 is NOT a duplicate of this one.
Any birthday cake, here ?
http://dascritch.net/blog.php/post/2008/10/23/Les-dix-ans-dun-bug

Comment 299

9 years ago
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?

Comment 301

9 years ago
(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)

Comment 303

9 years ago
(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?
Depends on: 2212
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: 2212

Updated

9 years ago
Duplicate of this bug: 486524

Comment 308

9 years ago
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.

Comment 309

9 years ago
Also reported in ubuntu/launchpad: https://bugs.launchpad.net/bugs/353877
Duplicate of this bug: 497269

Comment 311

8 years ago
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).

Updated

8 years ago
Flags: blocking1.9.2?

Updated

8 years ago
Flags: wanted1.9.2?

Comment 312

8 years ago
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-
Duplicate of this bug: 512421

Comment 315

8 years ago
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.
Comment hidden (offtopic)
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
Comment hidden (offtopic)

Updated

8 years ago

Updated

8 years ago
Duplicate of this bug: 547182
Comment hidden (spam)
Comment hidden (offtopic)
Duplicate of this bug: 589617
Duplicate of this bug: 589619
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
Last Resolved: 19 years ago7 years ago
Resolution: --- → INVALID

Updated

7 years ago
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.