RE: Styling table columns--why so limited?

> [Original Message]
> From: Jukka K. Korpela <jkorpela@cs.tut.fi>
>
> On Mon, 29 Mar 2004, Ernest Cline wrote:
>
> > > Could someone please point me to a discussion of the rationale
> > > behind such limited style options for the colgroup and col elements?
> > > I'd like to know why the spec doesn't allow for something as
> > > important as "text-align" and other styles on those elements.
> >
> > It's fairly simple. First of all, what text is there to be aligned?
>
> The text in the cells that are in the columns that correspond to the
> colgroup or col element.
>
> > In HTML neither <COL> nor <COLGROUP> has text.
>
> But they designate columns or column groups, which contain cells, which
> may contain text. And why were those elements included into HTML if you
> cannot use them for their defined purpose, to refer to columns and column
> groups? Specifically, the align="..." attribute is allowed in those
> elements, so browsers are expected to deal with the issue somehow.
>
> > Because
> > inheritance works only from parents, a table cell can't inherit
> > from the column or the column group element unless inheritance
> > is fundamentally changed in a way that would make it far less
> > efficient.
>
> Inheritance is just a concept defined by CSS specifications; it "works" as
> the specs define it. It's already a mess, and a constant source of
> confusion among authors, but maybe the benefits justify this.
> (Or maybe not. With the universal selector and with other "advanced" -
> i.e. post-CSS1 - selectors, inheritance would be mostly not needed, and
> is often undesirable, but maybe it's too late to change that.)
>
> The specs _already_ specify complicated ad hoc rules for the effects of
> setting properties for columns. Maybe the complexity stems from estimates
> on the complexity and cost of _implementation_ of CSS support in browsers,
> but I don't quite see the logic (I never saw a good explanation).
>
> I guess the basic problem is still in the definitions. What one would
> probably want to say is that if a property is not set for a cell,
> then it inherits it from the row element, _if explicitly set_ for it,
> and from the column element otherwise. But the information about being
> explicitly set is lost in the cascade. All elements possess all
> properties. This principle surely simplifies implementations.
> But it complicates specifications and comprehension, and implies some
> restrictions.

The problem is that given the way tables are defined in CSS,
There is no way to determine which column a cell belongs to
at the proper point in the cascade.  The problem stems from
having to support the results of CSS declarations such as:

<col />
<col style="display:none" />
<col />

Now, assuming the default UA style sheet, the third <col >
element represents the second column as far as CSS
is concerned.

> The practical implication is that we have to set e.g. right alignment for
> a column specifying a class for each cell in it, so people ask why not use
> just align="..." attributes, or even use <col align="...">, which works
> in the great majority of browsing situations, though this might be
regarded
> as a bug, too.

Nope, the problem is that the CSS and HTML table models
don't interact well.  To get them working well together, it easier
to modify HTML than to modify CSS.

> > However, not all is lost.
> - -
> > You can use the + combinator to approximate the missing
> > :nth-child in Gecko (and if you are trying to style just the first
> > or the last column :first-child and :last-child are available.)
>
> While this might be an interesting hack, when used to cope with some
> minority browsers along with the practical <col align="..."> approach,
> it's really not something anyone wants to sell to authors. Why would they
> move to such complexities when much simpler and more natural and
> structural methods exist in HTML? Who would want to style his paragraph
> by counting the elements before it and then styling it as the 42nd child
of
> the 7th son of the 7th son?

We were talking tables, not paragraphs.  If you have a table cell
element for every virtual table cell, then every cell in the 42nd column
of a table will be the 42nd child of a table-row, assuming that you don't
start getting pathological.  Defining how CSS handles pathological
cases is necessary and perhaps the method currently used by CSS
is not the best one, but so long as the model handles normal cases
correctly, it matters little.  For tables that don't have cells than span
multiple cells, the current CSS works fine.

> If the table model of CSS is so much more complicated than that of HTML
> (which is fairly complicated after all), then maybe this model should be
> simplified to produce something that can be used for practical styling of
> real tables, instead of all the fictional formatting of supertables or
> abstract tables that a more general model would cover.

The complexities come from two sources:
1) Having to be able to handle pathological cases.
2) How to handle colspan and rowspan.

The first is what prevents CSS from using the HTML model
of column inheritance, and quite frankly, unless one special
cases property inheritance involving the <col> and <colgroup>
elements of  HTML, this problem cannot be solved for CSS.

If you don't use colspan or rowspan then with existing CSS and
HTML there is no problem with applying style to columns
except a lack of implementation support.

Adding colspan and rowspan to CSS and requiring the source
document to provide an element for every cell in the table
would enable CSS to do anything HTML can currently do
with tables and the inheritance model would be much simpler
than that of current HTML.

CURRENT MODEL
<table>
<col span="2" /><col align="right" />
<tr><td rowspan="2" /><td colspan="2" /></tr>
<tr><td /><td /></tr>
</table>

PROPOSED MODEL
<style> tr>:last-child {text-align:right}</style>
<table>
<tr><td style="rowspan:2" /><td style="colspan:2" /><td /></tr>
<tr><td /><td /><td /></tr>
</table>

Received on Tuesday, 30 March 2004 18:05:16 UTC