Why is styling table columns not allowed?

Question

W3 specifies that only four CSS rules are allowed for table columns (with the <col> element) - border, background, width and visibility.

Does anyone know the reasons behind this decision? If you can have borders and backgrounds, why not fonts and colours?

Dakar

Answer 1

Ian Hixie explains in detail here: The mystery of why only four properties apply to table columns. Relevant quote:

The colour of text is dependent on the 'color' property of its element. Unless specified, the 'color' property (basically) defaults to 'inherit', which means "take the value of the parent element".

So for some text in a cell, the colour is determined by the 'color' property of the cell, which is taken from the row, which is taken from the table, which is taken from the table's parent, and so on.

What about the column? Well, the column isn't one of the cell's ancestors, so it never gets a look-in! And therein lies the problem.

Rosol

Interesting post. A lot of it makes sense, but it doesn't explain why those 4 CSS rules are allowed, but the others not. Surely the parsing model needed to be modified to apply backgrounds, so why backgrounds but not text colors? – Dakar

The column has the background colour. If the cell and row have a background colour of transparent, you can see though to the column colour. This is just layering elements on top of each other. Font colour doesn't work like that. – Rosol

Answer 2

Just a wild stab in the dark based upon my limited understanding:

I think styling via column related elements is restricted because although <col> and <colgroup> represent columns of cells, it does not actually contain them (they're actually contained by the <tr>s). With this comes issues of precedence and specificity and cascading (since cascading can only be done between contained/ container elements) - when conflicting style rules from the <tr> and <col> (which would be the same level in a multiple inheritance hierarchy) occur - which should the cell actually use?

As to why that particular handful of style attributes is permitted though: no idea.

Snuffer

For conflicts, the page I linked to says that cells take precedence over rows, then columns. So any style on a column is applied unless overridden at the row or cell level. – Dakar

Answer 3

One word: ambiguity. The cells have to be children of rows; it wouldn't be a table otherwise. But there is no column to descend from. Using colspan means that one cell could be in two columns. Rather than trying to come up with some confusing way out, why not just let the developer place a class on every nth cell?

If you look closely at the spec to which you link, you will see attempts at ambiguity resolution. The width property specifies a minimum; the background takes a backseat to the row and cell; and border references a "conflict resolution algorithm". The only reason there is even an algorithm for border is because it is reasonably understood who should "win" (see the algorithm for details). But could you imagine trying to figure out which color or font should "win"?

Aundreaaunson

Eh, what would be the difference between @colspan and @rowspan? – Inducement

@ms2ger: with a colspan, the cell spanning multiple rows is always a descendent of a specific <tr> element. – Dakar

@George: Good answer but one question... If I'm looking at the right place, the "conflict resolution algorithm" simply lists the order of precedence: cell (highest), row, row group, column, column group, table. Why can't that be applied for color or font? – Dakar

Answer 4

Possibly because each row in the table does not necessarily have to display a cell for your column (e.g. because of a colspan). Which column should that cell inherit it's style from? Just a guess.

Hadley