Whether you frame the argument as “divs vs tables”, “tables vs pure CSS” or whatever there are some strong opinions out there. I’m all for the idea of semantic markup. The problem? There are some things you can do (sometimes trivially) with tables that with CSS are:
- not compatible with IE6 (or even IE7 potentially);
- done with a fixed or partially fixed width layout but can’t be done a liquid layout;
- approximate facsimiles but have cases where they break down (eg if two side-by-side floated divs are too wide for their container one will drop below the other); or
- just downright impossible.
But rather than rehash that debate I simply want to put up my list of what I think CSS3 needs to be able to do. More importantly, it needs to be done trivially.
1. Vertical Centering in Fixed Height
Vertical Centering in CSS, with it’s relative+absolute+relative positioning with three nested divs is a prime example of a non-trivial equivalent to “vertical-align: middle” on a table cell.
2. Vertical Centering in Variable Height
The previous technique can be applied to this problem too but things start getting messy and some trivial cases start to get hard.
3. Fixed Column Layout
Any number of fixed-width columns can be done trivially with “pure” CSS. The standard technique is to use floats. There are two problems with this technique (compared to tables):
- If the content in one of the columns stretches it, your “columns” can drop off below; and
- There is no automatic equalization of height. You can give each column a fixed height but one of the beauties of tables is that all cells in a row automatically have the same height.
CSS3 needs to do better.
4. Liquid Column Layout
A frequent question on the Web is people wanting a “pure” CSS solution that will have a fixed column (on the left or right) with the other div taking up the remaining space, making this a liquid layout.
The standard technique alternative to a table with one fixed column is to use floats and negative margins, which is rather unintuitive.
5. Full Window Height
Again this can be done but to get cross-browser support you have to use the right combination of CSS attributes on the right elements. It just needs to be easier.
6. Fixed Height Header with Full Window Height
The standard technique for this seems to be absolute positioning of the header and adding padding to the top of the content or columns so they’re properly 100% height. We need a more intuitive solution.
7. Variable Height Header with Full Window Height
For example, How can I convert this table based layout to CSS? demonstrates a trivial table-based solution to the problem of full height where the header height is unknown. I’ve seen no adequate CSS solution to this problem to date.
8. Sensible Numbered List Styling
It still astounds me that HTML then CSS only provided one way of styling numbered list items (ie “1.”). Particularly because other variants are arguably more common (eg “1)”, “(1)”). I’ve seen so many pseudo-lists rendered with tables to get around this problem (floats and negative margins should also work). This one I consider to be a particularly bad use of tables but there it is.
Oddly, the solution to this seems to be Generated content, automatic numbering, and lists. Having counters I guess is useful for chapter headings and the like but it’s completely overkill when all I want to do is style a list item. We need better.
9. Sensible Column Spacing
This is another one that just astounds me that it’s still a problem. Going back to HTML 3.2 up to the present day, there are various methods of putting space around, say, table cells. The problem is that all these solutions ignore the most common (in my experience) use case for tables.
Let’s say I need a table with 7 columns. I want that table to be the full width of the container. I just want a gap between each cell in each row. Using margins or padding I’ll end up with extra space on the left and/or right where the cell doesn’t go quite to the edge. The current solution for this is to treat the first or last cell different by adding a class to it or using inline styles.
Now with CSS3 this will get easier thanks to the :last-child and :first-child pseudo-elements but honestly, why can’t we just have a CSS attribute on tables that controls the space between cells putting space to the far left and far right?
10. Related Variable Height
Tables give you for free the ability for cells in the same row to have the same height. We need to be able to tell the browser that two (or more) cells will have exactly the same height without specifying a fixed height.
Suggestions of using display: table-cell (when supported widely enough) raise the inevitable question: well if you’re using table layout anyway, how is a div with table-cell display any better than a td?
11. Related Variable Width
Imagine you’re producing a report of some kind that has a number of tables on it. Those tables show essentially the same type of data but you might have one table per state, for example. Generally speaking you want those tables to have the same cell widths. The only way to do that currently is to give each cell a fixed width. This isn’t particularly flexible and if content in one table stretches the cell width the whole system breaks down anyway.
One (nasty) workaround to this is to generate the entire report as one table with, say, 7 columns (assuming the table per state has 7 columns). The table has no borders. The content in between the “tables” is merely a single row of that table with a colspan of (in this case) 7. That way the tables will layout exactly the same and can be variable width too.
CSS3 needs to provide a better solution for “related” layout like this.
12. Anchoring Blocks to the Bottom of Containers
Place content (particularly floats) at, say, the bottom right of a container is a real problem.
The Elephant in the Room
There is a lot of talk lately about CSS3 and HTML5. What we seem to be ignoring is that we’re still supporting IE6 and probably will be for at least a year or two more. To get HTML5/CSS3 support we’re looking at Chrome 4+ (3 partial), FF 4+ (3.5/3.6 partial) and IE9+.
How long will it be before those browsers (which mostly don’t exist yet) account for over 90% of users? It’s no wonder the HTML5 roadmaps goes out to 2022. So does any of this matter? Won’t we simply be developing against HTML4 and CSS2(ish) for years to come?
Conclusion
I see a lot of talk about “cool” features like animations in CSS3. Personally I wish the W3C CSS working group would spend a bit more time dealing with real problems that cover common usage patterns.
But then again, even if they do, will it even matter?
Posts
