something about a missing colframe...

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.

Using 11/30 devprev build. Re-opening bug. Behavior in the first column heading is incorrect. Of the 4 column headings, only the first has a COLGROUP element tag and it has a value of align=left; therefore, the first column heading should align left (IT DOES NOT). The other column headings do not have attributes and should slign to the default - center (they do).

Let me correct my comments. The COLGROUP element only spans one column which would only apply to the 'Element' heading. This column heading should align left and it does not.

changed summary to reflect the real problem. see discussion summary at http://warp/client/raptor/table_column_style_resolution.html

*** Bug 1129 has been marked as a duplicate of this bug. ***

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.

*** Bug 19040 has been marked as a duplicate of this bug. ***

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

Adding 'beta1' to keywords. Beta1 should support CSS1 styles for all elements.

Pierre and I agree that we do need to get this fixed; if we don't, COL and COLGROUP are fairly useless. However, if push comes to shove, I'll be comfortable release noting this for beta 1 because (1) the W3C CSS1 test suite doesn't test this, and (2) no existing browser supports this, so there isn't existing content using it that will break. I think this is a "like to have" for beta 1 (but I wouldn't stop ship for it) and a "must have" for FC beta and FCS.

Putting on PDT- radar for beta 1.

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

*** Bug 7471 has been marked as a duplicate of this bug. ***

pierre/karnaze/troy: What was the WG's decision on text-align 'inherting' through columns in CSS like it does in HTML? david: cc'ing you, you might be interested.

*** Bug 25935 has been marked as a duplicate of this bug. ***

Updating summary to more accurately reflect the bug.

I'm CCing myself and attempting to summarize this bug after running into it in some work I was doing and spending time reading through it and the dups: This bug is cause by a contradiction between the CSS2 spec and the HTML4 spec. http://www.w3.org/TR/REC-CSS2/tables.html#q4 states that "The following properties apply to column and column-group elements: 'border', 'background', 'width', and 'visibility'" However, http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4 permits the 'align' attribute on COL and COLGROUP elements. If the 'align' attribute is to be equated to the 'text-align' property, this contradicts the above secion of CSS2. Mozilla's current behavior complies with the CSS2 spec, however because the 'align' attribute does not inherit from COL/COLGROUP, it violates the HTML4 spec. Restricting column inheritance to such a narrow group of properties also appears to violate the intended purpose of the COL element, namely "The COL element allows authors to share attributes among several columns without implying any structural grouping." Limiting the 'attributes' to those specified by CSS2 greatly reduces the usefulness of COL/COLGROUP. Moreover, code which relies on a wider range of columnar property inheritance is already extant, because IE supports it. A request for clarification to the W3C CSS working group is pending.

Moving off to M16 while we wait for clarification from the WG.

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

PDT- removed from beta1; nsbeta2 added.

sacolcor@provide.net: HTML align inherits from COL/COLGROUP, but CSS text-align doesn't inherit from COL/COLGROUP. HTML align is not the same as CSS text-align. For example, HTML align can center the block-level element, but CSS text-align can't.

Having layout control attributes in HTML that cannot be emulated using CSS seems to violate the intended seperation between using HTML for structure and CSS for layout. Is there a reason that text-align (and other properties) shouldn't inherit from COL/COLGROUP?

Yes. Inheritance works over the document structure. CSS doesn't know beforehand what element is a column, or what is a cell, or what is a block. That is all determined by the display property. If you propose general inheritance from COL/COLGROUP, what if I had the rule COLGROUP { display: table-cell; } ? Would the inheritance be determined by the element name or the display type?

IE seems to support cells inheriting from col and colgroup (at least color). Dave, are you saying that the specs don't support this type of inheritance in general or just for text-align.

I'm saying that in terms of CSS, it's wrong. (Although perhaps there could be a special exception for text-align on table-column elements...) However, it's required for HTML.

I can see the difficulties with 'display', however there are many properties (text-align, font, color, etc), that I can see authors wanting to apply on a columnar basis fairly frequently. It now sounds like there is no way to accomplish this without breaking the 'HTML is not for presentation' rule. Is there a 'good' way to resolve this dillema using current specs? If not, are the working groups attempting to resolve it in a future one?

IE 5.5 for Windows supports inheriting of 'text-align' from COLGROUPs and COLs.

CSS2 Spec. 17.3 says that 'border', 'background', 'width', and 'visibility' apply to column and column-group elements. (http://www.w3.org/TR/REC-CSS2/tables.html#q4 ) |Table cells may belong to two contexts: rows and columns. However, in the |source document cells are descendants of rows, never of columns. Nevertheless, |some aspects of cells can be influenced by setting properties on columns. | |The following properties apply to column and column-group elements: | |'border' (snip) |'background' (snip) |'width' (snip) |'visibility' And CSS Spec. 9.10 says CSS 'direction' doesn't inherit from column, but HTML4 "dir" inherits from COL. ( http://www.w3.org/TR/REC-CSS2/visuren.html#direction ) |Note. The 'direction' property, when specified for table column elements, is |not inherited by cells in the column since columns don't exist in the document |tree. Thus, CSS cannot easily capture the "dir" attribute inheritance rules |described in [HTML40], section 11.3.2.1. What about 'text-align'? Probably 'text-align' should not inherit from column and column-group since it is not listed in 17.3 as exception. Win IE 5.5 is wrong. On MacIE 5, HTML4 "align" and CSS 'background' inherit from column, but CSS 'text-align' and 'color' don't inherit from column.

>On MacIE 5, HTML4 "align" and CSS 'background' inherit from column, It was not accurate. On MacIE5, HTML4 "align" inherit from COL and CSS 'background' applys to column (but doesn't inherit from column). CSS2 Spec. 17.3 is not relevant to inheritance. If cell simply inherits 'background' from column, border-spacing would not be painted. But border-spacing should also be painted.

| Win IE 5.5 is wrong. On MacIE 5, HTML4 "align" and CSS 'background' inherit | from column, but CSS 'text-align' and 'color' don't inherit from column. Does 'background' inherit from column? It really shouldn't. As a matter of fact, background should never be inherited (if you haven't asked for it by using 'background: inherit').When using 'background' on COLs and 'border-collapse: collapse', table celles should have a transparent background, which makes the background on COL(GROUP)s shine through. In the same way, borders should *apply* to COLs, but not be inherited to cells. IMHO, the best thing would be if 'text-align' *was* inherited from COLs, but this isn't stated in the CSS specification (or in the errata). So, if 'text-align' on columns isn't meant to be inherited (something which isn't entirely clear), I think the CSS-WG should consider this for a future errata/CSS 3.

This is another COL/COLGROUP not yet implemented in CSS bug. According to the logic expressed in bug 29055, this is being moved out since it won't get into beta2. See bug 29055.

*** Bug 38917 has been marked as a duplicate of this bug. ***

*** Bug 43727 has been marked as a duplicate of this bug. ***

*** Bug 44981 has been marked as a duplicate of this bug. ***

*** 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'.

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

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

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

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.

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?

hixie: Why do you think <col align="center"> is deprecated? This is in the strict HTML4 and XHTML1 specs, AFAICS. And Mozilla does not render that correctly (see testcases 3 & 4). Or are you talking about other attributes?

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

Oops, my apologies. "align" and "valign" are not yet deprecated. Erich: Per CSS, <col style="text-align:right; vertical-align:bottom"> should have no effect. This is purely an HTML thing. See CSS2, section 17.3.

reassigning to glazman and marking m1.0.

I don't understand this assignment. Does it mean that a dual inheritance is expected in CSS tables ? I was a member of the CSS WG when it designed CSS2 and I am pretty sure that the CSS WG will not accept dual inheritance from TR and COL/COLGROUP. The list of properties applying to COL and COLGROUP has been voluntarily restricted to border, background, width and visibility, and the others have been voluntarily excluded from the list because of implementation concerns and difficulty of the model if we allow 'text-align' to apply for instance. Just for the record, I implemented such a dual inheritance for CALS tables (and HTML tables derive from CALS) in a former life and it was a nightmare. Please confirm if you want me to raise the issue (even if I am pessimistic) in the CSS WG. About the HTML issue which is the original purpose of this bug, this goes beyond my actual knowledge of the cascade implementation and raises a new question : what is the specificity of an HTML alignment specified on a COL/COLGROUP ? A cell in a column is not, structurally speaking, a descendant of the column... * w

Daniel: This bug is only about the implementation of the HTML 4.0 Transitional attributes. Their specificity is zero per CSS2. We implement that using the "mapped attribute" stuff in element classes.

Doesn't seem like this should be hacked at any CSS level. Seems like the table code should just check this special case when it queries for alignment WITHOUT actually mutating the style context data for a cell.

*** Bug 77466 has been marked as a duplicate of this bug. ***

*** Bug 77465 has been marked as a duplicate of this bug. ***

IMHO, dual inheritance of table cells is fully corresponding to common sense. Logically, table is a 2D matrix, which has both peer dimensions. Therefore, all CSS attributes of <COL> must be inherited in corresponding cells.

Did Microsoft voluntarily exclude "color" (IE supports it)? Tables can only implement inheritance that stops at the cell. IE's implementation of foreground color applies to all elements below the cell. This issue has been unresolved for 3 years. If it is so difficult to implement at the style system level, I wonder how IE does it.

This issue has been unresolved for years because nobody has yet come up with a theoretical proposal explaining how things *should* work. If you do that, then maybe we could discuss how hard it would be to implement. But until that happens such discussion is meaningless.

I think IE is following a very simple (and intuitive) strategy for "color" by considering <tr> inheritance as primary and <col> inheritance as secondary. IE lets a <td> (that has no matching non-user-agent [nua] color rules) inherit color from its <col> (if there are matching nua color rules) if there are no matching nua color rules on its <tr>. It could get more complicated by considering inline vs external style, important, user vs author, but I'm not sure how IE handles that. So, I guess an important rule on the <col> would win out over a normal rule on the <tr>. That's my proposal.

Basically, what you are saying is "TD inherits from COL if there is nothing on TR" which comes down to a regular inheritance chain "COL -> TR -> TD". I don't understand why you mention "non-user-agent" rules. Also things should not get more complicated with important rules and/or external style. Don't let IE confuse you as it did for me again in bug 103596. We inherit computed style (duh), not style rules. Anyhow, I thought that this bug was about the inheritance of HTML attributes, not CSS style. From a style standpoint, things are fairly well defined.

*** Bug 51693 has been marked as a duplicate of this bug. ***

*** Bug 111835 has been marked as a duplicate of this bug. ***

Shouldn't OS be changed to all? At least I have that problem on Linux (2001120221).

*** Bug 114341 has been marked as a duplicate of this bug. ***

*** Bug 115504 has been marked as a duplicate of this bug. ***

*** Bug 123001 has been marked as a duplicate of this bug. ***

Moving from Moz1.0 to future-P1. All bugs scheduled for Moz1.0 need to nominated using the nsbeta1 keyword.

not critical for mozilla1.0

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

Here is a proposal: HTML4 specification section 11.2.4 says that %attrs; (including STYLE) are valid attributes of COL and COLGROUP. All CSS properites that have "Applies to: ALL" should apply to COL and COLGROUP. HTML4 specification section 11.3.2 describes an order of precedence for inheriting attributes (VALIGN, LANG, DIR, STYLE) by content and children of TD such as P. NOTE there is a different order of precedence for attributes ALIGN, CHAR, and CHAROFF. This order of precedence should apply to all CSS properties that have "inheritence: YES". And to be perfectly clear, all CSS properties that have "inheritence: YES" and "Applies to: ALL" should apply to all HTML table elements (including TABLE, COLGROUP, COL, TBODY, TR, TD) so they may be inherited by the content and children of TD. That is my proposal. I think this bug should be fixed for Mozilla 1.2 if not sooner. I agree with comment #81. You cannot apply a strict tree model for inheritance in a table because a table is fundamentally a matrix (2D), not a linear tree. Otherwise it's just a fancy list of lists. Apparently the folks at Microsoft agree. What about CSS2 section 17.3? I think the properties listed there (BORDER, BACKGROUND, WIDTH, VISIBILITY) are intended to apply to the column as a whole element and probably not be inherited. Infact, CSS2 explicitly describes this for BACKGROUND and I think the same behaviour should work for BORDER. Therefore this section excludes ONLY these properties from inheritance by TD. This restriction should not apply to other CSS properties that apply to ALL elements and can be inherited.

That proposal contradicts section 6.1.1 of CSS2 (and also 6.2), which says that inheritance works on the document tree. If this is fixed, it should be fixed only for HTML (unless the CSS spec is changed, which I think is unlikely). I think this should be fixed by implementing HTML4 11.3.2 in the attribute mapping code, and always applying the mapping to the cell rather than relying on CSS inheritance. Note that this makes dynamic changes tricky.

Actually, all we'd really need to put in the cell attribute mapping code would be alignment for the cell and for the col and colgroup.

I take back the comment about attribute mapping. It would have to be a specialized rule managed by HTMLStyleSheetImpl that matched relevant TD elements and overrode the attribute mapping for TD.

I could live with an exception for (X)HTML, but not just for alignment. It should be for every CSS1(2?) property that applies to all elements and that inherits, unless there are some properties that should not be included for specific reasons. Thank you for referring me to section 6.2 of CSS2. After re-reading the definition of the document tree and the inheritance rules, I now understand why this behavior is not valid CSS2. This is in response to comment #84 asking for a proposal for how things *should* work so that it could be discussed. In the scope of HTML, I think TD *should* behave this way regardless of what CSS2 says. HTML4 is not perfect. CSS2 is not perfect. They disagree on TD. Therefore a "better" browser may choose the "better" way of doing things. Yes, this opens the pandora's box of opinions on what is "better". Maybe it contradicts CSS2, but IE sets a precedent that makes very good sense to me. The HTML4/CSS2 model is supposed to separate the structure of a document from it's stylistic formatting. So why does CSS2 impose the structural rule that each element may have exactly one parent? With this rule in place CSS2 is inadequate to style the contexts of a two-dimensional table. HTML is supposed to describe the structure of a document, and it says a TD can inherit style from more than one "parent" element. Regarding document structure, I think (X)HTML should trump CSS2. Besides, common sense agrees with HTML4 and not CSS2. A TD element needs to have two "parents" in order to illustrate it's relationship to the two axes of the table. TD and TH may be unique in HTML in this respect. One "parent" has priority over the other. HTML specifies that rows trump columns.

would not section 17.5.1 suggest an unambiguous inheritance hierarchy? http://www.w3.org/TR/1998/REC-CSS2-19980512/tables.html#table-layers -matt

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

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

regarding comment 101: While its true mozilla doesn't draw backgrounds the way CSS2 17.5.1 says, this bug 915 doesn't concern backgrounds or other properties that are not normally inherited. Table backgrounds in mozilla are covered by bug 4510. css2 doesn't seem to allow inheritance from COL to TD. (X)HTML does. I think the principle of CSS2 17.5.1 should be applied to inheritable properties.

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

*** Bug 147931 has been marked as a duplicate of this bug. ***

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

*** Bug 176338 has been marked as a duplicate of this bug. ***

Here's my 2 cents. Re:comment #86: "TD inherits from COL if there is nothing on TR which comes down to a regular inheritance chain COL -> TR -> TD". How about letting only text-align inherit from COL and COLGROUP and let vertical-align inherit from TR? That's how I would implement this. There would be no conflict to resolve. Re: comment#100: One "parent" has priority over the other. HTML specifies that rows trump columns. I believe this is what CSS2 also says when both x and y axis are involved like borders. Here's an illustration of this in 17.6.2: "If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table" I agree also that HTML align is quite different from the css property text-align. HTML align often implies positioning the element within its immediate parent node; text-align implies text alignment of the text node within the node. The css equivalent of HTML align in block-level elements involves the margin property, not text-align. So, within this way of definition terms, within this frame of understanding, <col align="left|center|right|justify|char"> does not strike me as "natural". I believe this whole issue would be a lot easier to solve if HTML align, char, charoff attributes would be deprecated for COL, COLGROUP and TR and css properties only would be applied. I would also deprecate valign for COL, COLGROUP and TR. HTML COL CSS prop. HTML TR -------- --------- ------- align text-align align char text-align:<string> char charoff ?text-indent? charoff valign vertical-align valign First(left) and last(right) columns would be deprecated; only way to style a table would be to use the middle column. CSS prop. text-align and text-indent would apply to COL, COLGROUP only while vertical-align would apply to TR only. (Of course the TDs would have the final word in the inheritance propagation on text-align, text-indent, vertical-align properties.) In other words, a text-align property applied to a td would only inherit from its COL or COLGROUP while a vertical-align proprerty applied to a td would only inherit from its TR. Please tell me if I'm making sense... I could present my reasoning/thinking/model in a demo... it would better illustrate all this.

I just visited one of my own pages ( http://futureboy.homeip.net/bjexec/hodds.exe ) and noticed that Mozilla has recently started to render COLGROUP's 'hsides' and 'vsides' rules correctly. The "Testcase from HTML 4.01 specification" attachment that I submitted above works correctly now also. There has obviously been some work done by someone at least tangentially related to this problem. In fact, my problems are finally solved. Thanks to whoever worked on this.

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

drunclear: two things 1: I don't agree with your suggestion for the mozilla developers to depreciate and never support HTML4 align and valign. HTML4 development is basically closed, right? So either mozilla will try to support HTML4 100% or it will not. I would like to see at least one version of mozilla format HTML4 tables 100% correctly before they depreciate parts of HTML4 for good. But this is just my opinion. 2: I would really like to see your examples. In particular I don't understand how the text-align properties are going to inherit from <col> using the CSS2 model, so I would like to see it in action. Thank you.

*** Bug 183917 has been marked as a duplicate of this bug. ***

*** Bug 193843 has been marked as a duplicate of this bug. ***

'background-color' on COL is *not* related to this bug, but may be related to bug 4510. This bug covers implementation of HTML's alignment attributes on COL and COLGROUP, for which HTML describes an inheritance algorithm that differs from CSS (and perhaps a general solution to what happens to inherited properties specified on COL or COLGROUP that would be nonconformant to CSS).

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.

on comment #123 I posted the attachment #115425 [details] because: - the Status Whiteboard sugest this is a non resolved issue - the summary list text-align - it works on IE 6.0SP1 (now I know that this issue is not well defined in CSS2, so this my be a IE hack)

I used all previous testcases(minus the height testcase) in this bug to make this simple testcase where people can compare what IE does. I don't think IE correct, but since there is no patch and no definitive solution, I wanted to show what IE does.

*** Bug 202998 has been marked as a duplicate of this bug. ***

IE also support align and style, set in "col"

Note that Safari v1.0b2 (v73) [kHTML based] renders honors the CSS background-color property in <a href="http://bugzilla.mozilla.org/attachment.cgi?id=115446&action=view">this testcase</ a>, and no other CSS attributes. Strongly request that CSS attributes flow to the TD elements, otherwise a great opportunity for functionality is lost.

Is there a projection on when this bug will be resolved (one way or the other), and what still needs to be done? Anyway, I second #116: "This bug has gone on for almost 2 years. Quit the debate. Pick a direction and go with it."

In the abscence of a clear standards-based direction (which it seems obvious that we have), I believe that this should be resolved toward compatibility with existing technology. Both IE and Safari have been mentioned as supporting similar cases, so let's just accept it as a defacto standard and implement it.

I described how this should be done in comment 97, comment 98, and comment 99. If somebody is willing to write a good (i.e., acceptable to the module owner and peers) implementation or hire somebody to write a good implementation, then the bug will likely be fixed. However, beyond that, see point 2 in http://bugzilla.mozilla.org/page.cgi?id=etiquette.html .

I chatted to dbaron about this and it seems a better solution would be to introduce new values for text-align and vertical-align (and theoretically possibly direction and lang) and have those values compute to either the HTML values based on the attributes present, or inherit the parent element's value, during the cascade, and then set td, th { text-align: -moz-table-cell-rules; vertical-align: -moz-table-cell-rules; } ...in the UA stylesheet. The exact computation for 'text-align: -moz-table-cell-rules' would be: If align is set on the element, use that, else if align is set on the appropriate <col>, use that, else if align is set on the appropriate <colgroup>, use that, else if align is set on the parent <tr>, use that, else if align is set on the ancestor <tbody>/<thead>/<tfoot>, use that, else if align is set on the ancestor <table>, use that, else if the element is 'td', inherit text-align from the parent element, else the element is 'th', use 'center'. The exact computation for 'vertical-align: -moz-table-cell-rules' would be: If valign is set on the element, use that, else if valign is set on the parent <tr>, use that, else if valign is set on the ancestor <tbody>/<thead>/<tfoot>, use that, else if valign is set on the appropriate <col>, use that, else if valign is set on the appropriate <colgroup>, use that, else if valign is set on the ancestor <table>, use that, else use 'baseline'. Then, we would remove attribute mapping for 'align' and 'valign' from <tr>, <tbody>, <thead>, <tfoot>, <col>, <colgroup>, and <table>. (We can leave it for <td> and <th>, since that then implies that we can skip the first test in the two lists above.) Now, from an implementation point of view, my mail problems are first of all, working out where computations happen, and secondly, how to determine which <col> applies to which <td> without highly inefficient walking around the DOM during the cascade. This also has to be able to cope with dynamically inserted <col> elements and stuff. Any suggestions would be very welcome. :-)

nsRuleNode.cpp, nsRuleNode::ComputeTextData and nsRuleNode::ComputeTextResetData seem to be the relevant functions.

One problem would seem to be that style contexts can (at least theoretically) be shared across elements with differing attributes or ancestors, and there is thus no way to check the attributes from the functions mentioned above.

One way of doing this would be to add two new internal properties, much like I think we do for 'lang', say '-moz-table-align' and '-moz-table-valign', which are non-inherited properties mapped from attributes, and then the '-moz-table-cell-rules' value on 'text-align' and 'vertical-align' would use those. So then the proposal becomes: ua.css would contain: td, th { text-align: -moz-table-cell-rules; vertical-align: -moz-table-cell-rules; -moz-table-valign: baseline; /* initial value */ } td { -moz-table-align: use-inherit; } /* initial value */ th { -moz-table-align: center; } Cells would then set their '-moz-table-align' value from attributes as follows: If align is set on the element, use that, else if align is set on the appropriate <col>, use that, else if align is set on the appropriate <colgroup>, use that, else if align is set on the parent <tr>, use that, else if align is set on the ancestor <tbody>/<thead>/<tfoot>, use that, else if align is set on the ancestor <table>, use that, else leave it. ...and they would set '-moz-table-valign' as follows: If valign is set on the element, use that, else if valign is set on the parent <tr>, use that, else if valign is set on the ancestor <tbody>/<thead>/<tfoot>, use that, else if valign is set on the appropriate <col>, use that, else if valign is set on the appropriate <colgroup>, use that, else if valign is set on the ancestor <table>, use that, else leave it. In addition, we would remove attribute mapping for 'align' and 'valign' from <tr>, <tbody>, <thead>, <tfoot>, <col>, <colgroup>, and <table>. The 'use-inherit' value would cause 'text-align' to inherit its value from the parent element. The disadvantages with this idea are that it is ridiculously convoluted and will take either lots of memory (two new properties and cached values for the attributes) or lots of CPU (every time the table is changed we need to recalculate all of this) or both, for what is frankly a deprecated feature with limited use. Can someone think of an easier/better way?

bernd just pointed out to me that there's some '#ifdef 0'ed code for this at: http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/nsTableCellFrame.cpp#1133 It fails to handle cases such as tr { text-align: center; } <tr align="right"> <td> this should be right aligned </td> </tr> ...but does help me since now I know there are easier ways of mapping table related attributes from columns. :-) It doesn't really solve the "dynamicness" as far as I can tell though; is there a way to say that attribute changes on the column should instead affect the text and vertical alignment of cells in that column?

Hixie: I doubt that in this case the text should be right aligned (or that it is well defined enough)

According to my reading of the HTML and CSS specs, they should all be right aligned, because the TR's attribute is equivalent to a selector that affects the cell, and there's no CSS anywhere to override it. I wouldn't mind making this a quirk, though. dbaron: What do you think? Should we be as strict as my interpretation? Or do you disagree with my interpretation? In any case, I was thinking about how to solve this, and I think I missed a step in my previous musings. As far as I can tell, we could actually do everything I described above without using any special values at all, just by moving all the attribute mapping code to the cells instead of the rows, columns, tables, etc. And in quirks mode we could still map the table, row group, and row attributes if required. Now, this is exactly what dbaron suggested in comment 97. dbaron: Can you remember why you changed your mind about how to fix this back then? I can't really see any obvious reason to.

> Now, this is exactly what dbaron suggested in comment 97. dbaron: Can you > remember why you changed your mind about how to fix this back then? I can't > really see any obvious reason to. Attribute mapping is based on creating a single style rule for any unique set of attributes on an element. What we want to do here might vary depending on the attributes of ancestors.

Comment on attachment 125172 [details] testcase css vs html attributes I think a literal interpretation of HTML4 leads to the conclusion that these should be center, center, and right, although if all the cells had STYLE="" attributes+values then they should all be right aligned. I think it's worth asking the HTML spec authors what they really meant before going ahead with anything that ridiculous, though.

Having looked at several different ways of implementing this, I can't see any sensible way of doing it without adding significant overhead that is simply not warranted by the rarity of this feature, especially given that it is deprecated, and that UAs that do implement this don't even do it according to the spec. This appears to be the only place in Gecko where attributes from elements that are only distant cousins need to be mapped to stylistic properties that do not affect the frame construction. Unless someone can come up with some workable solution, I'm going to effectively consider this WONTFIX.

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.

> Fwiw, comment 77 may be the most reasonable solution The problem with comment 77 is that the table code isn't the code that queries the text-align property. The block and line box code is. (As far as I can tell.) > if we can decide on precedence issues (eg, does an !important rule on <td> > override the align attribute on the <col>? Any explicit CSS on the <td> should override all attributes, whether !important or not, because the HTML attributes should be treated as CSS rules at the top (lowest specificity and earliest order) of the author level of the cascade.

Yes, but the table code has no knowledge of the cascade.... so it has no way to tell, e.g., style set via ua.css from style set via inline style, from nothing set at all. So _if_ we try to do this via the table reflow code, _then_ we need to give style system consumers a way to determine the "origin" of the computed style. Truth be told, we could use such origin-determination anyway; if we had it, we could greatly simplify (and make more correct, probably) the nsITheme styling of form controls.

> ... that is simply not > warranted by the rarity of this feature, especially given that it is > deprecated, ... Ian: Align/valign for COL, COLGROUP, TH, TD, THEAD, TBODY, TFOOT and TR is NOT deprecated by HTML4.01 specification. Or do you mean anything other?

adam: Presentational attributes in general are deprecated in favour of CSS, although I will grant you that the explicit text of the specification may not always call this out. In any case, such attributes will not be found in XHTML2.

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

charles allen: > so... the bug should be fixed. Are you volunteering? > CSS2 cannot do it. CSS could, actually, you just need to select the cells rather than the columns.

*** Bug 29055 has been marked as a duplicate of this bug. ***

Bug #29055 was "Resolved" as a duplicate of this one. #29055 had a Severity of "major". Further, the workaround requires setting either an attribute or class in EACH cell of an affected column, which is a burden for large tables. Thus, this bug should be "major". See my comment #26 for bug #29055 for a test case.

.

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

*** Bug 229798 has been marked as a duplicate of this bug. ***

*** Bug 233052 has been marked as a duplicate of this bug. ***

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

*** Bug 240096 has been marked as a duplicate of this bug. ***

*** Bug 240096 has been marked as a duplicate of this bug. ***

*** Bug 240096 has been marked as a duplicate of this bug. ***

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.

(In reply to comment #162) The blog entry seems to suggest that CSS2 on the one hand requires the graph of inheritence relationships to be a directed tree (with edges from ancestors to descendatns), and on the other hand necessitates, due to column inheritance, a inheritence relations graph which is a DAG (i.e. can have edges from vertices to non-pancestor edges while not forming cycles). So which is it? What does the standard actually require? Or is there an internal contradiction? Also, the blog entry seems to suggest more such cases become relevant in CSS3; could it not be the case that entry resolution using a DAG instead of a heirarchical tree will eventually be forced upon us (ok, ok, upon you) regardless of whether we like it or not (performance- and footprint-wise)?

I can't see where has this been deprecated, according to W3C technical report at http://www.w3.org/TR/html4/struct/tables.html#h-11.3.2 alignment attributes are not deprecated on table elements. But if Ian is right and Mozilla is not supposed to be an HTML agent then it changes everything...

Please explain how the horizontal or vertical alignment of table cell contents specified via the col or colgroup elements is deprecated (per comment #162) when both alignments are specified in the HTML 4.01 Strict DTD without any such qualification.

Using presentational HTML of any kind is deprecated. The only reason those specific attributes aren't labelled as such is that in 1997 when the spec first came out, CSS1 couldn't do tables. There's a note to this effect in the 1998 second edition but true to HTML form, it fails to actually explicitly deprecate anything. If you ask the HTML working group, though, they will happily tell you that yes, any use of HTML for presentational purposes is deprecated.

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

The CSS group agree that it is a CSS problem. They just haven't solved it yet.

Ian, I think Mozilla developers should follow W3C's way of thinking about this - support presentational HTML (at least on table columns) until there's a CSS way to do it (but judging from the comments here I doubt that there ever will be, that's why I think Mozilla should support the HTML way of doing this).

Yes, we all agree that this should be fixed. But see comment 162.

The comments about performance are a little misleading here, by the way. While I'm not disputing that there would be a performance hit if we accepted something like the alignment attribute, that would be a hit compared to having unaligned data. It should be compared to the extra time taken if there were alignment properties/classes set on every single cel in the column - and some consideration should also be given to the additional server time and pipe bandwidth (and therefore overall time) given to that solution. At least, that's the way I see it.

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

*** Bug 245939 has been marked as a duplicate of this bug. ***

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

The difficulty seems to stem from the desire to have styles on a table cell inherited from a col tag that is not an ancestor of the cell in the document object tree. Is it at all possible to make the col tag behave less like a separate element and more like an attribute of the parent table element that contains it? If the table somehow stored the styles defined on its col tags, then the cells in that table could inherit from the table tag since it is a direct ancestor. Also, that would allow inheritence to work in the expected order: table, col, tbody, tr, td. Any thoughts on that?

(In reply to comment #175) > The difficulty seems to stem from the desire to have styles on a table cell > inherited from a col tag that is not an ancestor of the cell in the document > object tree. Is it at all possible to make the col tag behave less like a > separate element and more like an attribute of the parent table element that > contains it? If the table somehow stored the styles defined on its col tags, > then the cells in that table could inherit from the table tag since it is a > direct ancestor. Also, that would allow inheritence to work in the expected > order: table, col, tbody, tr, td. Any thoughts on that? This is exactly the way i see the things. The cell is the ultimate child and should inherit from all the parents. I also agree with the order: table, colgroup, col, tbody,tr,td . (colgroup is col's parent)

Comment 175 and comment 176 don't help anything. The whole problem is that it's not possible in the CSS to inherit from more than one parent and nobody has described anything resembling a vaguely sensible way of doing so.

(In reply to comment #177) > Comment 175 and comment 176 don't help anything. The whole problem is that it's > not possible in the CSS to inherit from more than one parent and nobody has > described anything resembling a vaguely sensible way of doing so. The whole of CSS involves cascading through multiple parents - whole ancestral hierarchies. Moreover, these hierarchies are complex, as ancestors may receive attributes through various types of rules of varying specificity. This "it's not possible" (like most!) is I think designed to stifle rather than to encourage creative discussion. With the complex inheritance picture in CSS, surely the issue is one of priorities. CSS already has procedures for resolving priorities; for example, an attribute prescribed by a more remote ancestor may be overridden by a more proximal one (e.g. a DIV attribute may be overridden by a P attribute). As many commentators have said, COLs and COLGROUPs complicate the picture because they don't fit the DOM tree like other CSS properties. Nevertheless, they do provide a natural way to prescribe those horizontal layout properties, i.e. width and alignment, that programmers need to provide in tablular reports. Some of us, who have to do a lot of tabular reports and who don't like writing repetitive cell-by-cell alignment attributes on every line of an n-line table, take the view that COL or COLGROUP is the natural way to do these things. So, what is the problem? In particular, if COL can be implemented for width (as the powers-that-be have decreed it should), what is the problem with implementing it for alignment also? To claim (as has been claimed for years in this topic) that this is an inheritance problem seems to me unfounded. If it is an inheritance problem, why can COL and COLGROUP be successfully used to specify width? And what is this inheritance problem that uniquely affects alignment? - Let me see if I have this straight. Consider the example: Assumption 1: Cell (3, 2) is at column 3, row 2. Assumption 2: Column 3 prescribes text-align right. Assumption 3: Row 2 prescribes text-align left. If I understand the inheritance problem correctly, then Cell (3,2) could arguably be left-aligned (inheriting from Row 2) or right-aligned (inheriting from Column 3). Baron et al seem to be alleging that in the absence of a definitive ruling from W3C, there is absolutely nothing that a user agent (e.g. Mozilla) can reasonably do except wash its hands of the whole business and wait for interminable deliberations of the appropriate international committees. Yet several previous commentators have pointed out that one could use some consistent principles of logic, e.g. that COL has precedence over TR on horizontal attributes (e.g. width, text-align) while TR has precedence on vertical ones (e.g. height, vertical-align). But first of all, let's consider the (usual, in fact typical) situation where there is no conflict between row attributes and column attributes on column width or alignment. Although COL cuts across the DOM tree - columns intriniscally do - as a matter of fact all user agents already manage to harmonize respective column widths from row to row; so if it is not beyond the wit of man to give them equal width, why not common colour or alignment? What deep conceptual or inheritance problem was overcome in order to manage equal column widths on every row? why can that conceptual or inheritance problem not be solved for other attributes? But what if there is a conflict? What if the row prescribes attributes that conflict with the column attributes? I (and I suspect many others who have contributed to this topic) don't care. If the inheritance rules are stupid or awkward or unpredictable, I don't care. If one user agent does it one way, and another does it another, I don't care. Because at the end of the day, if I prescribe row properties that conflict with column properties, then it lies within my power to stop doing so.

(In reply to comment #178) > The whole of CSS involves cascading through multiple parents - whole ancestral Elements never have multiple parents. They may have multiple ancestors, but never multiple parents. And CSS inheritance only deals with the parent. Yes, the parent may in turn inherit from its parent, but CSS inheritance is easy to define because it's only concerned with the parent.

In reply to comment #179: We shouldn't try redefining the problem just in order to save implementation work. Yes, in general CSS inheritance only depends on the parent element. But why can't there be a special case for tables with COL elements?

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

(In reply to comment #181) > (In reply to comment #180) > > Yes, in general CSS inheritance only depends on the parent element. But why > > can't there be a special case for tables with COL elements? > because nobody has explained how that special case would work It should work the same way that width and other COL attributes work already today. What's the difficulty?!

> What's the difficulty?! Read comment 162 carefully. Not a single CSS specialist/guru has solved that problem yet.

(In reply to comment #178) In case of conflicting attributes the best thing is to do ...nothing, i mean let's use the default setting.

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

Rather than having a special case of multiple-inheritance, is it not possible to define an ancestor-only direct hierarchy for application through CSS that does not necessarily match the DOM? While the DOM hierarchy may be: <table> <colgroup> <col /> </colgroup> <tbody> <tr> <td> ... </td> </tr> </tbody> </table> would it not be possible to keep a modified DOM tree for CSS purposes that looks like: <table> <tbody> <tr> <colgroup> <col> <td> ... </td> </col> </colgroup> </tr> </tbody> </table> Is this the terrible performance hit that's being described, the need to watch for changes to the DOM tree and replicate it (with changes) for a separate CSS tree?

Mmh. The CSS3 selector spec (http://www.w3.org/TR/css3-selectors/#nth-child-pseudo) contains the following example: tr:nth-child(2n) /* represents every even row of a HTML table */ which I assume could as well have been td:nth-child(5) /* represents every 5th column cell of a HTML table */ which AFAIU would provide (almost) exactly what COL does. So my question is: Don't css-selectors 'break' the style cascade in the same way a COL does? And to reiterate an unanswered question: What is so special about the width property of a COL as compared to its align property?

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

What sort of algorithm is it which "applies the style"? It seems quite trivial in a depth-first traversal of the document tree to count column numbers without undue overhead.

(In reply to comment #188) > > So my question is: Don't css-selectors 'break' the style cascade in the same > > way a COL does? > No, because we can calculate which element is the fifth child of its parent > before we do layout: all you have to do is look at the DOM tree and count the > prior siblings. Well, the problem why COL stylea re not applied to a cell seems to be because a cell is not a descendant of that COL and it's not easy (or possible) to apply a style that's not inherited. But a 5th cell also looks at more than its parent when calculating its style, now why exactly is looking at a column more difficult than looking at how many child nodes does a cell's parent have? Both involve traversing the DOM tree up AND down (to a parent and down to each child for n-th selector, to a table parent and then down to n-th COL for a COL style).

Does this whole discussion sidestep display: table-column/table-column-group? The suggestion that this is merely a deprecated HTML hack seems to ignore other elements styled as table columns. Using td:nth-child(n) is not going to work for rows that contain cells that span columns. Would it be possible to treat the COL/COLGROUP alignment info as if it were an attribute (array) of the TABLE itself? This way, inheritance would work a little more consistently.

The fifth child of a TR may not be the fifth row if there are colspan or rowspan elements prior. But thanks, Stefan Moebius, for suggesting a workaround. If I can get a test case working demonstrating the workaround, would that be grounds for dropping this bug's severity to "minor"?

"Row" in my last comment should read "column". And no, Stefan's suggested workaround doesn't work because Gecko doesn't yet recognize :nth-child (bug 75375; target: Future; no new patch since Q2 2001).

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

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

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

> I hate to butt-in but isn't this fixed via CSS? No, it isn't. You can give the second cell in each row a class of "itemcost" or some such, but you begin pushing back the HTML/CSS boundary of good-design. Being able to simply say that the second column is of a class would be clearer, shorter, and a better separation of content and display.

I've seen sites use a workaround involving adjacent and first-child selectors of CSS2. According to a page on DevEdge, these selectors work in Mozilla, in recent Opera, and in IE for Mac but not in IE for Windows. You can use it too until this bug gets FIXED. Does this CSS2 workaround demote the bug to minor?

That "workaround" has the same problems as the n-th child "workaround." i.e. comment 151 and your own comment 152 still apply: spans will mess up the intended rendering.

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

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

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

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

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

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

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

Please forgive me for butting in, but I just joined Bugzilla and this quirk has been aggravating me for a long time. I have read all of the comments on this bug, and fully understand the issues involved, originating with the CSS single inheritance model and exacerbated by the lack of clarity in the CSS specifications about how this particular case should be handled. With respect to what should be done, I wholeheartedly agree with the sentiments expressed in comment #100 (and elsewhere): > Regarding document structure, I think (X)HTML should trump CSS2 and > I could live with an exception for (X)HTML, but not just for alignment. It > should be for every CSS1(2?) property that applies to all elements and that > inherits, unless there are some properties that should not be included for > specific reasons. Styles defined on COLs and COLGROUPs should affect the table cells in those columns. ALL appropriate (inheritable) styles, be they approved in CSS2 17.3 (like 'border', 'background', 'width', and 'visibility') or not (like 'text-align', 'font', 'z-index', even the aural properties and preferably also 'display:none'). With respect to tables, CSS2 6.1.1 and 6.2 are an incorrect adaptation of document structure. CSS3's ':nth-child' psuedo class is an inadequate workaround, because of cells that span multiple columns. But common sense (and HTML4) dictates that CSS2 and CSS3 must be overridden here; tables are two dimensional structures and table cells are contained by both rows and columns. IE understands this and Mozilla should too. This way, we honor the intended purpose of COLs and COLGROUPs while still separating content (HTML elements) from style (CSS rules). Once you decide that HTML4 should trump CSS structure but not CSS rules, then the issue becomes how to apply the update in a logical, efficient, and minimally changed manner. The idea presented in comment #186 is to modify the DOM tree for applying CSS rules (in other words, to create a pseudo-tree for TABLEs): > <table> > <tbody> > <tr> > <colgroup> > <col> > <td> ... </td> > </col> > </colgroup> > </tr> > </tbody> > </table> This would work, but it involves a non-trivial change on every table and breaks the symmetry between DOM structure and CSS ancestry. I vote for the method suggested in comment #175 and comment #191, that is, treating COLs and COLGROUPs more as attributes of TABLEs than as independent elements. comment #175: > The difficulty seems to stem from the desire to have styles on a table cell > inherited from a col tag that is not an ancestor of the cell in the document > object tree. Is it at all possible to make the col tag behave less like a > separate element and more like an attribute of the parent table element that > contains it? If the table somehow stored the styles defined on its col tags, > then the cells in that table could inherit from the table tag since it is a > direct ancestor. Also, that would allow inheritence to work in the expected > order: table, col, tbody, tr, td. Any thoughts on that? comment #191: > Would it be possible to treat the COL/COLGROUP alignment info as if it were an > attribute (array) of the TABLE itself? This way, inheritance would work a little > more consistently. The inability of COLGROUPs to contain anything but COLs and the inability of COLs to contain anything at all lend credibility to treating them as attributes of TABLEs... indeed, this seems to be their purpose. Programmatically, it doesn't seem like this change would affect very much. It would probably be the most efficient change in terms of processor cycles, and would only take up more memory where more would be needed anyway (when COLGROUPs and/or COLs are specified). It honors the intent of both HTML4 and CSS2, and would even work for the CSS 'table-column' and 'table-column-group' display properties. Well, I think my proposal is finished. I am amazed at the longevity of this bug, and hope that I can help resolve it.

(In reply to comment #207) > been aggravating me for a long time. I have read all of the comments on this > bug, and fully understand the issues involved, originating with the CSS single > inheritance model and exacerbated by the lack of clarity in the CSS > specifications about how this particular case should be handled. With respect If you think there's any lack of clarity in the CSS specifications, then you don't fully understand the issues involved.

(lack of clarity on this issue, that is)

I think Richard Gibson's proposal should be implemented as it sounds plausible to me. David Baron, could you please explain specifically why his proposal is wrong?

The key problem is here: (In reply to comment #207) > I vote for the method suggested in comment #175 and comment #191, that is, > treating COLs and COLGROUPs more as attributes of TABLEs than as independent > elements. This would mean, unless I'm misunderstanding what you propose, that any styles associated with TR, THEAD, TBODY, and TFOOT would override those on COL and COLGROUP, which is not what the HTML spec says should happen.

Note that applying stylistic attributes on inner table elements to the cell (rather than acting as though they were attached to the the table) doesn't have these problems. Then again, I proposed that in comment 97 - comment 98 - comment 99.

I am part of this thread because I reported bug #265838 after finding an inconsistency with other browsers (IE and Opera). All this talk about how the rules of CSS inheritance should be interpretted is really becoming annoying, so let me add to the debate my throwing in my two penny's worth. AFAIAW the rules of CSS inheritance are quite clear. You may specify style at various levels, and entries at lower levels override anything specified at a higher level. Thus within an HTML document style may be specified at any of the following levels: (1) Browser defaults (Why are they all different? Why are they never documented?) (2) External stylesheets (from CSS files). (3) Internal stylesheets (between <style>..</style> tags). (4) At the individual tag level. It is therefore quite clear to me that anything specified within a COLGROUP tag overrides ANY previous specification, and it may only be overridden itself by other specifications within that particular table. Thus if I specify <colgroup valign="top"> I expect all relevant cells to be aligned at the top (regardless of any current setting for TD tags) UNLESS I specify something different on a particular TD tag. Also bear in mind that the rules of CSS inheritance can only be strictly applied in XHTML documents where inline style is disallowed. As HTML documents can have a mixture of both then you must deal with that mixture and apply the style in the order in which it was specified, which may be from a mixture of stylesheet and tag info. As a final point, regardless of how any individual *thinks* the rules should be interpretted, you should start by being consistent with other browsers.

(In reply to comment #212) > This would mean, unless I'm misunderstanding what you propose, that any styles > associated with TR, THEAD, TBODY, and TFOOT would override those on COL and > COLGROUP, which is not what the HTML spec says should happen. My reading of the HTML specification comes up with a totally opposite conclusion. If you go to http://www.w3.org/TR/html4/struct/tables.html#h- 11.2.4.4 and scroll down beyond the sample table you will read: <quote> We have set the value of the align attribute in the third column group to "center". All cells in every column in this group will inherit this value, but may override it. </quote> This is reinforced with the section entitled "Inheritance of alignment specifications" at http://www.w3.org/TR/html4/struct/tables.html#h-11.3.2.1 which clearly states the following: <quote> The order of precedence (from highest to lowest) for the attribute valign (as well as the other inherited attributes lang, dir, and style) is the following: - An attribute set on an element within a cell's data (e.g., P). - An attribute set on a cell (TH and TD). - An attribute set on a row or row grouping element (TR, THEAD, TFOOT, and TBODY). When a cell is part of a multi-row span, the attribute value is inherited from the cell definition at the beginning of the span. - An attribute set on a column grouping element (COL and COLGROUP). When a cell is part of a multi-column span, the attribute value is inherited from the cell definition at the beginning of the span. - An attribute set on the table (TABLE). - The default attribute value. </quote> Can you show me ANYWHERE in the HTML specification that says that the valign attribute on any COLGROUP or COL element is to be ignored?

The point is that the order of precedence for a bunch of other attributes (see the paragraph just before the one you quoted) is the opposite regarding rows and columns, and the solution you're strongly advocating is no easier to implement than the one in comment 97 - comment 98 - comment 99 but leads to significantly worse results.

(In reply to comment #217) > The point is that the order of precedence for a bunch of other attributes (see > the paragraph just before the one you quoted) is the opposite regarding rows and > columns, and the solution you're strongly advocating is no easier to implement > than the one in comment 97 - comment 98 - comment 99 but leads to significantly > worse results. I'm not concerned about how easy or not it is to implememnt. That's your job. The HTML specification clearly states the order of precedence, so I expect a standards-compliant browser to follow that order. If it does not, then it is not a standards-compliant browser and therefore unworthy of consideration by serious professionals who are constantly frustrated by all these different browsers which insist on 'doing their own thing'.

(In reply to comment #217) I've been staying off the chilli for a couple of days and maybe I can say something more constructive. No doubt the rules in the HTML or CSS specifications do give some kind of order of precedence. Maybe the specifications are ambiguous. But many of the people who write web pages, and generate data tables on a terrifying scale, are actually very simple people who want to write simple code that doesn't exploit subtleties in the inheritance hierarchy. We keep our styles simple, specific and well-targeted. We ensure that our elements aren't larded with lots of overriding styles that might come out this way on one browser, and that way on another. In particular, when producing a table, I (and other simple souls like me) are never ever going to play precedence games with the alignment of a column. And if we do, and things didn't go right, we would think that we had only ourselves to blame. If I have a column with four columns of text and one of numbers, I want the numbers right-aligned and the text left-aligned; and firing out td elements with alignment styles on each and every one of N rows times M columns just goes against our simple-minded principles, and we feel that (X)HTML plus CSS ought to be able to go one better. We pea-brains do not understand why, when we do not want our browsers to distinguish complex inheritance rules that we ourselves cannot understand and frankly have better things to do, they cannot even understand basic instructions. Thus, when I have absolutely no styles whatever in my document except that I specify right-alignment for a numeric column via a col or colgroup element, I rate a browser that totally ignores my directives as inferior to one that tries to carry them out, however imperfectly. So what I am suggesting is that if Mozilla did the smallest, meanest, measliest thing towards recognizing a col attribute and applying it, then even if it flew in the face of abstruse precedence rules, I would be content, because I can always construct my XHTML to avoid reliance on precedence rules. And I think it's important not to lose sight of the purpose of (X)HTML, which is to present information. People like myself who are furiously polluting the web with data for (ugh!) ordinary consumers are actually trying to supply good- looking accessible information first, and while we all no doubt like to follow standards and get one of those nice W3C tick-mark or check-box logos on our pages, that is a means to an end. We want something that works cleanly and well and is easily maintainable. When the quest for perfect fulfilment of standards actually frustrates us who are trying to get them to work for us, it seems to me that there is something self-defeating going on. When, for example, I read (as I seem to do here) that it is reasonable of me to expect that I can control colour or background via a col element, but if I want alignment too then I am a simpleton who needs a smack on the head, I just feel we are losing touch with reality. It's like having a car with a steering-wheel that works the automatic indicators OK, but doesn't actually change the vehicle's direction. Stupid boy. Finally, I prefer to work with something that tries to get it right, rather than something that doesn't try for fear of getting it wrong. The point of a browser is to be usable, isn't it, rather than to satisfy a small committee of gurus? I apologize for my last stroppy antagonistic post. But I really do think that a change of priorities is called for.

None of the solutions proposed is easy to implement. I really don't understand why you're advocating doing it wrong when it's just as easy to do right.

(In reply to comment #220) > None of the solutions proposed is easy to implement. I really don't understand > why you're advocating doing it wrong when it's just as easy to do right. Ok, so for the "correct" solution here (which is apparently hard to implement), if someone comes up with a patch to do it that way, will it get checked in? Comment 131 seems to indicate yes, but the general tone of the comments from Mozilla devs on this bug seems to contradict that: I feel like any patch submitted will either "touch too many parts of the code" or "be too complicated", and be rejected on intangible, highly-subjective grounds. As someone else has remarked, if this bug really isn't going to be fixed, please mark it as WONTFIX so we can all stop wasting time here. If a fix _is_ possible and likely, then my question to all the people CCed on this bug is this: is there someone capable and willing who can write a patch implementing the fix as dbaron has described? If so, speak up, and get to work. It seems to me that it's pretty clear how dbaron (et al.) want this bug fixed, and arguing isn't going to do a thing about it, so if you're not capable and willing, there's no reason for you to add another comment to this bug. I've been watching this bug for several years now, and I'm getting tired of most of the useless whining that goes on here. This is a bug report, people, not Slashdot.

I've got a few ideas, so I'm taking this. No guarantees, and, if you look at 4510, you'll see that I'm a slow coder. So don't expect anything anytime soon--but I'm guessing no one else will take this even if I don't, so I'm putting it on my list. I actually did find comment 219 useful, there were a few helpful points there. Suggestions about altering the DOM are not useful--we're definitely not going to do that.