- From: Ernest Cline <ernestcline@mindspring.com>
- Date: Fri, 2 Apr 2004 16:52:12 -0500
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: www-style@w3.org
> [Original Message] > From: Ian Hickson <ian@hixie.ch> > > On Fri, 2 Apr 2004, Ernest Cline wrote: > > > > I already have, if you want me to look up a reference to the post > > I will, but it's simple enough I'll repeat myself. > > I thought you said it wasn't good enough, which is why I had not taken it > into consideration: > > http://lists.w3.org/Archives/Public/www-style/2003Dec/0101.html It wasn't but that wasn't the post I was referring to: http://lists.w3.org/Archives/Public/www-style/2003Dec/0105.html is the one where I concluded trying solve this with only CSS was not likely. There are a few typos in it (such as a number of <th>'s ended by </td>'s which appear thruout because I cut and pasted the example table that ad the original error) but it goes into the idea with more explanation. > > Implement a second table model. it would be much the same as the current > > one except that 'rowspan' and 'colspan' would be CSS properties and > > would cause the cells to overlap other cells in the source document > > instead of requiring them to not be there. > > I'm not sure what you mean. > > The problem is solve is: Given this HTML markup snippet: > > <table> > <colgroup> > <col id="a"> > <col id="b"> > <col id="c"> > </colgroup> > <tr> > <td id="d"> > <td id="e"> > <td id="f"> > </tr> > <tr> > <td id="g" colspan="2"> > <td id="h"> > </tr> > </table> > > ...and this CSS: > > #b { display: none; } > #a { color: purple; } > #c { color: blue; } > > ...find a way to ensure that d and g end up purple and e ends up blue, > with f and h remaining unstyled. Huh? Even if CSS supported inheritance from columns, You've given the table a third row with your pathological example because of the anonymous table-row that will be generated around b. > How does your proposal solve this? It doesn't. It does an end run around the problem by changing the HTML to: <table> <colgroup> <col id="a"> <col id="b"> <col id="c"> </colgroup> <tr> <td id="d"> <td id="e"> <td id="f"> </tr> <tr> <td id="g"> <td> <td id="h"> </tr> </table> ...and the CSS to this: table { display:table-model2; } #b { display: none; } #g { colspan: 2; } tr>:first-child { color: purple; } tr>:nth-child(2) { color: blue; } which will produce the desired effect if I understood you correctly. > > The magical solution that will enable CSS to work with HTML tables that > > use the rowspan and colspan attributes without drastically changing the > > way CSS works doesn't exist. > > So it seems. But that is what people want. Agreed. But I don't think that it can be done. > > It is long past time to forget about trying to do this. Instead we > > should concentrate on how can CSS have a table model that does > > what HTML tables can do, even if it doesn't do it the same way. > > If it doesn't do it in the same way it is largely useless, since the > overwhelming majority of tables are HTML tables. Then perhaps CSS will need to support two table models, one intended to work with HTML/CALS tables where using colspan and rowspan causes the source document to omit table cells and another where even if they aren't intended to be displayed, the table cells that get spanned by other cells are included in the source document. The former would probably have to give up some or all of the flexibility of the CSS 2 table model, perhaps even reverting back to the CSS 1 table model for use as a starting point. Even then allowing inheritance by table-cells from column elements will probably be painful. > > This is one area where trying to maintain total backwards > > compatibility is not a good thing. > > Backwards compatibility becomes irrelevant when the thing you are being > backwards compatible _with_ has stopped being a prominent part of the > problem. In the current case, it is almost exclusively the _only_ part of > the problem. So being compatible with it is definitely a good thing.
Received on Friday, 2 April 2004 16:52:35 UTC