Bug 915 (col-align-inherit)

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

RESOLVED WONTFIX

Status

()

P4
normal
RESOLVED WONTFIX
21 years ago
20 days ago

People

(Reporter: kipp, Unassigned)

Tracking

(Blocks: 1 bug, 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

21 years ago
something about a missing colframe...

Updated

21 years ago
Status: NEW → ASSIGNED

Updated

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

Comment 1

21 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

20 years ago
Status: RESOLVED → REOPENED

Updated

20 years ago
Resolution: FIXED → ---

Comment 2

20 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

20 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

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

Comment 4

20 years ago
changed summary to reflect the real problem.

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

Updated

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

Comment 5

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

Updated

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

Updated

20 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

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

Comment 12

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

Updated

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

Comment 15

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

Updated

19 years ago
Keywords: beta1, css1

Comment 16

19 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

19 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

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

Comment 20

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

Comment 21

19 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

19 years ago
Blocks: 29055

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 24

19 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

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

Comment 27

19 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

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

Comment 29

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

Updated

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

Comment 30

19 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

19 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

19 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

19 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?
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
| 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

19 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

19 years ago
Keywords: testcase

Updated

19 years ago
Blocks: 43178

Comment 47

19 years ago
*** Bug 43727 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

19 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

18 years ago
Blocks: 43997
Comment hidden (obsolete)

Updated

18 years ago
No longer blocks: 43997

Comment 67

18 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

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

18 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

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

Comment 81

18 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

18 years ago
Blocks: 104166

Comment 82

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

Comment 83

18 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

18 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

18 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

17 years ago
Shouldn't OS be changed to all? At least I have that problem on Linux (2001120221).
*** Bug 114341 has been marked as a duplicate of this bug. ***
*** Bug 115504 has been marked as a duplicate of this bug. ***

Comment 92

17 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
not critical for mozilla1.0
Keywords: mozilla1.0 → mozilla1.0-
*** Bug 139569 has been marked as a duplicate of this bug. ***

Comment 96

17 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

17 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

17 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

17 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

17 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

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

Comment 106

17 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

17 years ago
Blocks: 2068

Comment 107

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

Updated

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

Comment 109

17 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

17 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

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

Comment 112

16 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

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

Updated

16 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

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

Comment 127

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

Comment 128

16 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

16 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

16 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

16 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

16 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

16 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

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

Comment 152

16 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

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

Comment 155

15 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

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

Updated

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

Comment 158

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

15 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

15 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

15 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

15 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

15 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

15 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

15 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

15 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

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

Comment 174

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

Comment 175

15 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

15 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

15 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

15 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

15 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

15 years ago
> What's the difficulty?!

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

Comment 184

15 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

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

Comment 186

15 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

15 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

15 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

15 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

15 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

15 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

15 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

15 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

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

Comment 195

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

Comment 196

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

-R

Comment 197

15 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

15 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

15 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

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

Comment 201

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

Comment 202

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

Comment 203

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

Comment 204

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

Comment 205

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

Comment 206

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

Comment 207

14 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.
Comment hidden (offtopic)

Comment 211

14 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

14 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

14 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

14 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

14 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

14 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

14 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

14 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

14 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

14 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

14 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

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

Comment 230

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

Comment 231

14 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

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

Updated

14 years ago
Flags: blocking-aviary1.1+

Updated

14 years ago
Flags: blocking-aviary1.1+

Comment 234

14 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

14 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

14 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

14 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

14 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

14 years ago
No longer blocks: 163993

Comment 240

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

Comment 241

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

Comment 242

14 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

14 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

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

Column attributes have no effect whatsoever.

Comment 245

14 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

14 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 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

14 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

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