RE: Styling table columns--why so limited?

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 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 situatons, though this might be regarded
as a bug, too.

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

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.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Tuesday, 30 March 2004 03:11:18 UTC