CSS 2.1 and tables

Let's return to nerdy stuff. This time I'll talk a bit about CSS 2.1, and its support on tables.

To begin, here's the link about what I'm talking about: CSS 2.1 tables, so you can read it if you like (you should, is not that long or complex).

A short intro: as you should know, Cascading Style Sheets are things used to inform the user agent how to display the page data. The philosophy is to separate content from layout. This have several advantages (as well as disadvantages):

1. The roles of content-producer and the website-layout-designer are well separated, the work of one doesn't shouldn't affect the other.


2. As direct consequence of the previous, you can give to users many different styles (also very different) or change easily your website, keeping the whole backend intact while changing the frontend. This is a major fact on reusable softwares like CMS


3. Semantic is well defined, and it doesn't mix-up with presentation.


4. This is why in this post, I'm using well-formatted html code: to show you that html mean something, while css show something. So, when you write <del>something</del>, you don't mean "a line on text" but "deleted content".


5. This helps search engines, semantic web and all this nice stuff.

Let's come to the problem: the CSS table support.

As you should know, using tables to format a web page is wrong. I'm not saying that "it's ugly" or that "it's better to do with CSS". I'm saying that it is wrong. Why? Easy: tables exists to format tabular data in a nice way. The meaning of a table is to show data like sequences, like poll results and so on, not to show "a nice and well formatted something". To say in a different and more clear way: you don't use Microsoft Excel to do a presentation! You use OpenOffice's Impress. That's it. Even if you can use Excel, it wasn't designed to do it, while Impress was made for it. (If you can do something, doesn't mean it's the right thing to do.)

All the above, doesn't mean that you can't show a web page like a table :) And this is where CSS comes in.
Is it wrong to use <table> your page </table>, but it isn't if you use a <div> and then format it like a table. How? With the CSS table model.

It is quite simple to do it. Instead of:

<table>
<tr><td>Col 1</td></tr>
...
</table>

you can just use CSS display property:

<style type="text/css">
div { display: table; }
p { display: table-row; }
span { display: table-cell;}
</style>
<div>
<p><span>Col 1</span></p>
...
</div>

This produces the same layout, but uses different semantic (actually, for a whole page, you may prefer to use div and classes, instead of paragraphs and spans).
This is great, because you will use tables for tabular contents and generic containers for your page semantic.

All the above is synthesized in the document linked above:

In a visual medium, CSS tables can also be used to achieve specific layouts. In this case, authors should not use table-related elements in the document language, but should apply the CSS to the relevant structural elements to achieve the desired layout.

Now, where's the problem? That table support in CSS2 just sucks, because it was done like HTML 4.

The CSS table model is based on the HTML4 table model, in which the structure of a table closely parallels the visual layout of the table. In this model, a table consists of an optional caption and any number of rows of cells. The table model is said to be "row primary" since authors specify rows, not columns, explicitly in the document language.

In addition colspan attribute is defined only for tables and CSS doesn't allow you do specify the span of a table-cell element. This means that you can actually build a table with divs, but you can't apply a colspan on them - which is really important if you use table-like formatting, because, probably, your layout won't look just like a grid :)

The choose of excluding colspan from the CSS2.1 specification is - at my advice - a bit wrong, because even if the semantic value of a spanned cell exist, it assumes importance also on the presentation of the table, because with a colspan you're saying "the same value hold for two or more cells", but also "show the cells as they were one".

Luckly in CSS 3 the attribute table-colspan is introduced, allowing a more flexible layout for tables.

Anyway, I feel that this table model is quite unhandy and inflexible (actually as the HTML model). Why row primary? I mean CSS is for defining layouts, and this seems a force to me: one should specify his content row primary (even if you're not using tables) because CSS needs it.
What if I'd like to change the layout of one table, flipping it on the XY axis (i.e. making rows be columns and vice-versa)? I should be able to do it just changing CSS and not the structure of my document.
Moreover (this is just an idea, an hypothesis so don't take it too seriously) I feel like the hierarchal structure of the document already gives information about table composition; if you write:

<parent>
  <child>
    <granchild>

you already know which-is-son-of-which, so it should be just a matter of choosing which-is-what (is child a row or a column? what about granchild?)

This hypothesis may held even for the table's semantic, but I feel it more important for it's display. How would you describe a table like this?

Column	Row 1
	Row 2
Row 2

First question: is this a table? It is... It seems... So, let's assume that "the tables set" includes also this one.
Second question: which is the semantic? We want to describe a table with 3 rows, and a property which holds for 2 of these rows, which is the column.
Please look yourself the code of this page to see it, if you don't know how to do it.
As you see, in the HTML we're forced to use rowspan and colspan, which are layout informations, but they are in the code! We're saying that a column should be 2 cell's height and another one is 2 cells wide. But, semantically speaking, shouldn't it be something like this?

[property id="p1"]Column[/property]
[data properties="p1"]Row 1[/data]
[data properties="p1"]Row 2[/data]
[data][/data]

This say: we have 3 rows, two of them have this property in common.
It should be my decision if represent data as rows and property rows in a color or as a new column, like this:

Row 1

Row 2

Row 2

Which can hypothetically be described with this pseudo-css:

property { display: none; }
data { display: table-row; }
data[property="p1"] { border: 1px solid red; }

..or if these properties should be shown as rows while the data are columns, like this:

Column		Row 3
Row 1	Row 2

Which can hypothetically be described with this pseudo-css:

property {
  display: table-cell;
  cell-position: top;
  unification: unify-adjacent;
}
data {
  display: table-column;
}

Aren't these the same data in different looks? To me, they are. So my opinion is that the whole HTML4 table model (and thus the CSS2.1 one) is incorrect, but since HTML was born with a double semantic (both of content and display), I guess that CSS is the wrong one.

I vote for a more flexible table model in CSS (4?). Since working with tables is really important and really liked when dealing with layouts (as many webmasters/designers still use tabled formatting nowadays), a new and more efficient table model would really help in designing layouts and, I guess, it would be really appreciated by the community, since it can produce easily pixel-perfect and cross-browser layouts which are capable of be represented on a variety of devices, even not graphical ones, because semantic still persists.

I hope that someone find this article useful and maybe be an inspiration for a future implementation of a powerful table model.

Stay --sync