W3C home > Mailing lists > Public > www-style@w3.org > April 2004

Re: Styling table columns--why so limited?

From: Ernest Cline <ernestcline@mindspring.com>
Date: Fri, 2 Apr 2004 16:52:12 -0500
Message-ID: <410-22004452215212953@mindspring.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:28 GMT