Re: Styling table columns--why so limited?

[Quite lenghty... Seek to "XXX" for yet another table idea.]

Ernest Cline / 2004-04-03 00:52:
>>From: Ian Hickson <ian@hixie.ch>
>>On Fri, 2 Apr 2004, Ernest Cline wrote:
> [...]
> 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.

The important thing to notice is that the proposed idea isn't 
backwards compatible with HTML markup. A "table" containing a cell 
that occupies more than one cell's space in the table cannot be 
represented with a common markup for both old-html-way and 
new-css-only-way. Yet they share common element names and namespace.

After saying that, I must agree that marking up every cell *does* 
make much more sense if we're talking about *tables*. A cell that 
has colspan or rowspan set is *logically* still a single cell, it's 
only that it's rendered over multiple cells. The original HTML 
markup has built-in compression scheme that requires the author to 
remove unneeded (invisible) cells from markup. As we're trying to 
describe a document as a structured tree, including ad hoc 
compression system doesn't make things easier. Yet that's something 
HTML does, for historical reasons.

If the target is to group table headers or something like that, then 
add a new element that can represent such information, instead.

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

Good point. I think this nicely illustrates the problem that raises 
from the fact that the 'display' property is over burdened. I'm 
afraid that table semantics should have different property and 
display element should just define if the element is contributing to 
rendered view or not. Or perhaps it's just the 'none' value that's 
contributing to the problem? Perhaps it should be dropped and the 
behavior should be replaced with 'remove' property that could have 
values 'true' and 'false'?

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

If I cannot refer to #a, #b or #c in the CSS, why should I markup 
the col elements at all? Wasn't the whole point to fix the col 
inheritance issue??

XXX Perhaps do it the other way around?

Let's have a yet another special keyword for all properties called 
'table-inherit' (or something). It would work so that the actual 
value used for rendering would be calculated on the fly 
on-the-need-basis and the on the fly computation rules would be 
constructed so that the column inheritance just worked for all 
properties that used 'table-inherit'. Still the issue of getting the 
col element out of the table when setting it's display property to 
'none' is there; how do we know that the col element is still part 
of the table (and so the 'table-inherit' should take it's value from 
that element) if the only hint to say so (display: table-column) is 
gone? Add yet another 'display' value 'none-but-still-table-column' 
(following the perl's "0, but true" logic :D) ?? I think it's 
do-able but far from nice.

OK, such a construction wouldn't still inherit "correctly" from the 
table columns, but the author could specify that some properties 
would be defined in the higher levels of the table. Define 
'table-inherit' carefully and it might be possible to make TD and TH 
by default to correctly inherit all the properties from col which 
are required by CSS2 (which limits the inherited properties). 
Inheritance of other properties could be requested by author by 
using the 'table-inherit' keyword.

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

I agree. If we cannot come up with something that allows using the 
*original markup*, then we could just redo the whole table markup to 
match with CSS's current limits. Never mind if the original HTML 
markup has some problems, we just have to cope with it.

-- 
Mikko

Received on Tuesday, 6 April 2004 10:04:46 UTC