This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
currently, browsers only apply background-color and maybe background-image css to col and colgroup elements. I don't know if this is the place for this, but I think it would be proper for col and colgroup, row, and rowgroup to at *least* have a class and a style attribute, and other "on..." events associated with the global attributes. also, MUCH more CSS would need to be applied to the col and colgroup, row and rowgroup elements, with the reasoning that whatever you can do with the row and rowgroup elements, you should be able to do with the col and colgroup elements. events, all kinds of css, etc. not sure if an id would make sense on a column - would it? maybe. depends on how you render it or treat it. I think row and rowgroup are logical companions for col and colgroup. I think they should have been there ever since tables began. If you had a red row and green col in a cross formation, I would think that the center would be red, unless the cell in the center has its own overriding color, because I would think the row has a higher priority, it being the closer-to-the-action element.
didn't know if I was on the cc list for this bug, so I put myself on. I don't think I am getting notified of changes to my bugs.
(In reply to comment #0) > currently, browsers only apply background-color and maybe background-image css > to col and colgroup elements. I don't know if this is the place for this, but > I think it would be proper for col and colgroup, row, and rowgroup to at > *least* have a class and > a style attribute, and other "on..." events associated with the global > attributes. > > also, MUCH more CSS would need to be applied to the col and colgroup, row and > rowgroup elements, with the reasoning that whatever you can do with the row and > rowgroup elements, you should be able to do with the col and colgroup elements. > events, all kinds of css, etc. not sure if an id would make sense on a column > - would it? maybe. depends on how you render it or treat it. > > I think row and rowgroup are logical companions for col and colgroup. I think > they should have been there ever since tables began. > If you had a red row and green col in a cross formation, I would think that the > center would be red, unless the cell in the center has its own overriding > color, because I would think the row has a higher priority, it being the > closer-to-the-action element. I know you said this was a separate bug for rowgroup, but it seems to simply DUPE Bug #11474 which you closed as WONTFIX. HTML5 already has elements representing rows ("tr") and row groups ("tbody"). Minting new names for semantics already long represented by HTML is a bad idea because you lose backwards compatibility. So there's nothing more for the spec to do here. The "col", "colgroup", "tr", and "tbody" elements already take the global attributes (including events, "class", "style", and "id"). So there's nothing more for the spec to do here. The application of CSS to these elements is a matter for the CSS WG, /not/ the HTML WG bug tracker. So there's nothing more for the spec to do here either. Can we close this bug?
skip the css. this is not essentially a css issue. yes, I closed that other bug as wontfix, but only because (notice the subject) it was about the CSS of col and colgroup. this is about new elements row and rowgroup. you can't expect joe web developer to read this bug report to know that tbody is supposed to group TR elements. also, the word tbody suggests that it is a container for the collective whole of the content of the table just like body suggests that it is a container for the collective whole of the content of the page. I do not think tbody is a good candidate as a row grouper. I don't think anybody expects it to be. I haven't seen any examples in any books which show it as such either (which also tells me what people are thinking, that tbody is a container for all the tr and td elements in the table). also, does tr have the span attribute and other attributes which are associated with col? they should have the same attributes. so ask yourself - why does col exist? it provides some useful benefits. same with row. If I have a section in a long table, I can save myself from duplicating my CSS formatting for every row by using 1 row statement or rowgroup statement with a span attribute. rowgroup should exist for rows for the same reason colgroup exists for col: to group col elements, if I am not mistaken. in fact, one of the nice things I can do is format 1 th line (skipping 10 td lines) with light green and repeat this over and over.
(In reply to comment #3) > you can't expect joe web developer to read this bug report to know that tbody > is supposed to group TR elements. Given than <thead>, <tbody> and <tfoot> are the only elements allowed to nestle between <table> and <tr>, those are the only candidates for grouping <tr> elements. The H:TML draft makes it fairly clear which elements are allowed inside <table>: http://www.w3.org/TR/html-markup/table.html#table And the definition of <tbody> linked to makes it pretty clear that <tbody> is intended for grouping rows: http://www.w3.org/TR/html-markup/tbody.html#tbody > also, the word tbody suggests that it is a container for the collective whole > of the content of the table just like body suggests that it is a container for > the collective whole of the content of the page. Changing an element's name can potentially break a lot of software. In particular changing <tbody> to <rowgroup> would break every browser that currently exists, thanks to HTML5's adoption algorithm and pre-HTML5 variants of it. Introducing a new <rowgroup> that complemented <tbody> would have similar effects. I'm not saying that element name changes should never be considered, but they are a major backcompat issue, so should only be done when there is an overwhelming reason to do so. > I do not think tbody is a good candidate as a row grouper. I don't think > anybody expects it to be. I haven't seen any examples in any books which show > it as such either (which also tells me what people are thinking, that tbody is > a container for all the tr and td elements in the table). Then you've not been looking very hard for examples. If you search Google for "html tbody examples" the first result contains an example of multiple <tbody> elements: http://www.htmlcodetutorial.com/tables/_THEAD.html So does the third: http://www.htmlquick.com/reference/tags/tbody.html As far as books are concerned, O'Reilly's "HTML & XHTML: The Definitive Guide" offers this definition of <tbody>: "Use the <tbody> tag to divide your table into discrete sections. The <tbody> tag collects one or more rows into a group within a table." The following section in the book contains a full example of a complicated multi-section table, including multiple <tbody> elements. > also, does tr have the span attribute and other attributes which are associated > with col? they should have the same attributes. No, there is no reason to add the span attribute to <tr> or <tbody>. The column span of a row or group of rows can be calculated by inspecting the table cells (<td> and <th> elements) within it. <col> and <colgroup> are empty elements (except for <colgroup> containing <col>) and do not contain any table cells themselves, so it's necessary to have a span attribute to make their spans explicit. Adding span to <tr> and <tbody> would result in some authors adding redundant information to the attribute. (Not needed because it can always be calculated.) Some authors would get the information wrong which would lead to a mismatch between what was specified in the attribute, and what could be calculated from the cells. I'm guessing browsers would go down the "trust the calculation" route as the alternative would make no sense (do you chop some cells out of a row or rowgroup?). Thus the contents of the span attribute would become universally ignored.
I guess tbody would not need a span attribute, since it is not a void element. I see where this problem is already solved. I am closing this bug.
mass-move component to LC1