Today, a talented web designer must be a modern-day MacGyver—that 80s TV action hero who could turn a rubber band and three tin cans into a serviceable aircraft. Turning the average site design mockup into a living, breathing slice of HTML and CSS is a comparably delicate miracle, which must be accomplished using whatever makeshift tools happen to be lying around in current browsers.
That’s exactly why so many professional designers still choose to use HTML tables for layout. How can we expect beginners to adopt CSS for layout when it takes someone with the resourcefulness (and snappy dress sense) of MacGyver to fully understand the techniques involved?
Thanks to the imminent release of Internet Explorer 8, CSS layout is about to become something anyone can learn to do—no chewing gum or makeshift explosives required.
HTML Tables Are a 90% Solution
HTML tables produce the grid-based layouts we want to achieve with relative ease, but the price is that users with screen readers and other technologies that rely on semantic markup have a hard time making sense of the page.
As standards-conscious designers, we have convinced ourselves that the benefits of semantically meaningful markup are worth the added hassle of using CSS for layout. Not everyone shares this conviction. Whenever I write about some new CSS layout technique, at least half the feedback I get boils down to “You’re kidding yourself if you think designers will use that instead of HTML tables.”
The reason this is such a contentious issue is that tables correspond so well to the way designers tend to think of pages: a semi-flexible grid that defines rectangular areas that make up the page. If you want three columns in a row, you just put three table cell tags inside a table row tag:
<table>
<tbody>
<tr>
<td>column 1</td>
<td>column 2</td>
<td>column 3</td>
</tr>
</tbody>
</table>The premise of using CSS for layout is sound: replace the HTML tables with semantically meaningful markup, plus semantically invisible divs where needed:
<div id="container">
<div>
<div id="menu">column 1</div>
<div id="content">column 2</div>
<div id="sidebar">column 3</div>
</div>
</div>The problem is the CSS code required to lay out this new markup. CSS was not initially designed to support blocks arranged horizontally across the page; consequently, we have had to get creative with the tools at our disposal. Current best practice requires the designer to master subtle interactions like overlapping floats, negative margins, and other black magic to achieve a simple multi-column layout. You don’t so much describe the layout you want as gradually build up a combination of positioning constraints that almost miraculously result in the layout you’re after. You couldn’t come up with a more convoluted way of expressing page layout if you tried!
If CSS layout code were as easy to write as HTML tables, making the leap would be a no-brainer; designers would flock to CSS willingly. Instead, we must drag them kicking and screaming, because the tools that CSS provides are not suited to the layout tasks we want to accomplish.
What if CSS provided a set of tools that applied to practical layout tasks as obviously as HTML tables do?
Bring the Tables to CSS
CSS actually includes a feature that works just like HTML tables: CSS tables. Using the CSS display property, you can instruct the browser to format any HTML element as if it were a table. For visual display purposes the element behaves like a table, but the element retains its non-table semantics for screen readers and other tools that look at the HTML markup.
In short, CSS tables let you perform table-based layout without misusing HTML tables!
The CSS to lay out our collection of divs above as a row of three table cells is very straightforward:
#container {
display: table;
border-collapse: collapse;
table-layout: fixed;
}
#container > div {
display: table-row;
}
#container > div > div {
display: table-cell;
}We can then set the widths of each of our columns, again with very straightforward code:
#menu {
width: 200px;
}
#content {
width: 66%;
}
#sidebar {
width: 33%;
}From this foundation, applying borders and backgrounds to these columns is trivial. Check out this sample page, and the screenshot below for a fully-rendered example. Now this is the kind of page layout code that designers can embrace with confidence!
Compared with HTML tables, CSS tables have only one notable weakness: CSS does not allow for table cells to span rows or columns the way they can in HTML tables (with the rowspan and colspan attributes). As it turns out, however, this is a relatively uncommon requirement for page layouts; and in the few cases where spans are required, there are ways to fake them with CSS tables.
Can You Start Now?
So, why isn’t everyone already using CSS tables for page layout? In an all-too-familiar twist, we have Internet Explorer to blame. CSS tables are supported in every major browser except Internet Explorer. However, the good news is that Internet Explorer 8 will have full support for CSS tables upon its release, setting the stage for CSS tables to become the preferred tool for page layout on the web!
The question you must ask yourself is, “When can I start making the switch?” The answer may depend on the type of site you work on.
If you work professionally on a mainstream website, chances are you will be expected to keep your site working on Internet Explorer 6 and 7 for some time to come. Since neither of these browsers support CSS tables, it may seem on the surface that you’re out of luck. In fact, CSS tables may still make your job easier.
Because CSS tables are so much easier to work with than previous CSS layout techniques, you may find it worthwhile to implement your design first using CSS tables, and then using older CSS techniques for IE6 and IE7. You can use conditional comments to insert your IE6/IE7 style sheet, while all other browsers will only get the table-based layout. This approach does mean you have to implement your layout twice, but it saves you the considerable headache of getting the older techniques from working both in Internet Explorer and in other browsers.
While you’re at it, you may find opportunities to simplify the layout slightly in the IE6/IE7 version of the site, and save yourself a lot of work. Something like not insisting that a column’s background color extend all the way to the bottom of the page can radically simplify the code, for example.
If you work on a site with a more technical audience, or owned by a more progressively-minded organization, you might have even more wiggle room. In this case, you should explore the possibility of providing a simplified page layout for IE6 and IE7. The sample page included with this article is written this way. In the screenshots below, you can see the page displayed in IE8 (beta 2) and IE6.
If you find yourself having to defend this approach to a client, tell them how much of your time (and their money) will be saved by simplifying the layout a little in outdated browsers.
Even if you can’t justify working with CSS tables in your day job just yet, it’s worth finding excuses to use them where you can. When Internet Explorer 5.5 made CSS layout across browsers possible for the first time, Jeffrey Zeldman wrote To Hell With Bad Browsers, leading the call for designers to adopt CSS layout:
“For years, the goal of a Web that was accessible to all looked more like an opium dream than reality. Then, in the year 2000, Microsoft, Netscape, and Opera began delivering the goods. At last we can repay their efforts by using these standards in our sites. We encourage others to do the same.”
The response to this call to action was gradual, but effective. Initially, web designers began experimenting with CSS layout on their personal sites, before testing the waters with some of their riskier side projects. Major mainstream sites like ESPN began making the switch only a couple of years later.
With Internet Explorer 8 on the verge of release, the stage is set for another wave of change to sweep the Web, however gradually. Now is the time to ensure you’re on the leading edge, not paddling to catch up!
Everything You Know About CSS Is Wrong
Perhaps the most important benefit of CSS tables is that it finally makes page layout with CSS easy to learn. Finally, we can justifiably expect anyone designing a web site today to do it the right way, with a proper separation of content (HTML) and presentation (CSS).
In my just-released book, Everything You Know About CSS Is Wrong (available from Amazon: Everything You Know About CSS is Wrong!
I get what you’re saying, but it bugs me when people refer to tableless design as “using CSS instead of tables”, which your article seems to do. You still use CSS when you design with tables. I think that makes it even more confusing for beginners.
“Why aren’t you using tables instead of CSS?”
“I am, my tables have CSS applied to them.”
See what I mean? The problem I think is that “layout” is too generic of a term to specifically mean “just the structure of the site”, because many people use layout to describe the structure as well as fonts, color, padding, margin, etc.
Thanks for the review of that technique and for proposing solutions for IE6 and IE7.
However, there are other problems with that approach that will prevent me from using it widely even when / if it’s supported by a large number of browsers across the board. As Alastair Campbell and others have pointed out on digital-web, one drawback of this technique is the inability to have full control over source order, which make us go back to the old days of tables layout in terms of accessibility (at least in some cases). That also show that it’s probably not a very good way of getting a good separation between presentation and structure. Another drawback is the (per specification) inability to position things relatively inside such a “cell”.
However, like every front end developer out there, I like the idea behind this (grid like capability for CSS). The Advanced Layout Module in CSS3 will give us that, while preserving freedom in terms of content ordering and relative positioning. Let’s hope that CSS3 modules gets out quickly and gets widespread support ! Thanks again for dissecting the technique !
[…] Here’s the introductory paragraph for the article, Tables: The Next Evolution in CSS Layout, which I found cute. […]
It’s the second article I’ve seen about CSS tables. What bugs me is they’re not educating what they should be educating. Next thing you know people will start using CSS table layouts as they use(d) HTML table layouts: sliced and diced images within “cells” without any semantic meaning.
I think more emphasis should be put on the mark-up.
PS. Second paragraph after the IE6/IE8 image: “Jeffrey Zeldmen”. Should be “Jeffrey Zeldman”.
[…] To that end, I’m glad to see that the whole problem has been addressed by inserting table-based layouts into the CSS spec. […]
Nice article, but until IE 8 has major dominance (in the IE market anyway) CSS tables won’t be a viable solution. Many folks won’t be able to justify building a site one way for compliant browsers, and a completely different way for the wonder twins (6&7).
I still want to hug the guy that came up with conditional comments though - they’re a friggin’ life saver.
It’s annoying that the only reason I’m not going to be using these is because of IE. IE still takes up 70% of the average usage share and I’m betting IE6 is still responsible for a good chunk of that 70%.
I’m currently working on my own project and the layout is CSS based. I’m interested to see what my target audience will be for this - if it’s got a seriously low number of IE6/7 visitors (probably wishful thinking) I may consider implementing this approach - but until then… we can’t without abandoning a portion of our user base.
One can use display:table for modern browsers and go with inline/zoom
for IE 6/7, check the
Float-less Layout Demo.
@ Paul, I think this is a limitation of CSS. If presentation and content and were truly separated in CSS - which I understood was the goal - then why shouldn’t a designer be able to have a DIV with no semantic meaning? Why can’t I use a CSS attribute to specify whether a container contains meaningful content or is merely a presentation device and should be ignored by screen readers, for example. I’m not sure what term I would use, how about “content: none”? “presentation-only: enabled”?
It’s all really said in the line, “the tools that CSS provides are not suited to the layout tasks we want to accomplish”. This is exactly the problem. I’m sure every web designer in the world has thought, “Why couldn’t the designers of the CSS spec look at the most popular website designs and give us the tools to do it in CSS, rather than dictate to us how we should be designing our sites?”. If separation of content and presentation had truly been achieved, this would not have presented a problem and everyone would have been happy. Is a three column liquid layout with all columns of equal height too much to ask?
Why can’t MS just push IE8 via Windows Update? or just upgrade the CSS engine of the IE6/7 via Windows Update?
Henry,
One reason is because a lot of businesses have had custom applications built to IE6’s buggy CSS implementation, so doing that would make it look like Microsoft broke their applications. They need to keep their customers happy before they make us happy.
@Paul Decowski - thanks, I spotted that typo on my first read-through but must have missed it during the edit. Now fixed :)
An interesting idea, and definitely an attractive example. However, your comparison between standard tables and your CSS tabled design doesn’t cut out much of the dead wood that is one of the reasons why people go tableless in the first place.
Another thing that bugs me is the pointless nested div with no class or ID, as it’s not very semantic.
Maybe I’ll stick with good old standard tableless design until the section tag comes out, when the flowing newspaper-style column functionality is supported… and the rest. Gulp.
CSS Table-layout is bad. It encourages really bad thinking, it encourages you to think in terms of slices, and using similar mindsets from 2000.
It’s a half-baked solution to the problem, that’s inflexible, and encourages redundant mark-up.
The trouble with CSS is that it has _only_ the cascade to work with. CSS needs to become more aware of the DOM and it needs to be able to inspect one DOM element in order to apply the attributes of that object back to a reference. CSS also needs an enhanced methodology for Generated Content, allowing it to wrap a given attribute. This would allow visual “skeleton mark-up” to be inserted using pure CSS instead of throwing in otherwise pointless DIVs.
http://mattwilcox.net/archive/entry/id/991/ - More about how CSS needs to enhance capabilities over just the Cascade, and how that finally buys us a true seperation of Content from Presentation.
http://mattwilcox.net/archive/entry/id/1016/ - Why the CSS’s ability to style only pre-existing DOM elements is a major problem to separating content from presentation.
[…] Tables: The Next Evolution in CSS Layout […]
Interesting. I was thinking about this problem these days and yesterday I wrote a post in my newly created blog about how we could solve the layout grid problem and easily accomplish a complete separation of presentation and content.
The problem with the CSS tables approach (and even any other CSS technique) is that if we want to change the layout grid we are likely to change the HTML anyway, depending on the layout complexity. So it’s not completely semantic, there are elements in the HTML which only purpose is to serve the CSS.
I’m trying to think in a method to avoid these problems that would work now in every mainstream browser. Then I come up with the idea of doing that with JavaScript, pretty much the idea of transforming XML documents with XSLT, but in a way simpler manner, that could be done in Dreamweaver for instance.
The main idea is tranforming HTML to HTML. That sounds odd, but the point is that the transformation would add the layout elements, tables etc, without affecting the semantic of the original HTML, that would be directly available through the browser’s “view source”.
I know there is CSS3 grid layout to come, which probably would solve this problem, but we don’t know when it will be available. I’d like to see something that can work right now. The full idea is explained in the article Why Tableless CSS Layouts Are Still Not Right.
When you use the display:table; etc. properties does the browser have to wait for all the content like it does when you use an actual table?
Even if it doesnt slow down the dom construction its a bloody stupid idea to use diplay:table; for non tabular data.
Please… CSS2 was published in 1998, and has five major ways of putting elements side-by-side:
- float;
- absolute positioning;
- display: inline;
- display: inline-block;
- display: table-cell.
Four out of five can be used for styling blocks (while still retaining most or all block formatting). Not designed for this, uh? Did you mean the short-lived CSS1?
The whole “Everything you know about CSS is wrong” thing sounds like people have finally read the f**king manual. Hellooo? 1998?
No. Current best practice requires the designer to use float in a sensible way, and to master overflowing floats. That’s two concepts, which is not as good as dealing with just one, but it’s pretty decent. By the way, using CSS tables mean you have to deal with some advances concepts too: table layout algorithms (I see fun moments in the future…), horizontally expanding table cells (“Why has my 980px layout exploded up to 1500px?”), etc.
And current best practice requires the designer to stay away from One True Layout techniques, which are basically a hack (a sensible fix in Firefox2 would have broken the technique, but there was feedback on that in the beta stage and the fix was unfixed…). Even if you consider them as legit, using them means the next person working on the site will probably not understand how it’s done, will not be able to change simple things, and may have to redo the whole layout. Creating additional costs using not standard convoluted techniques is definitely not best practice.
No. Use table-layout:fixed and give widths to the different “columns”.
It’s not a bloody stupid idea right now to use HTML tables for layout in the few cases where it’s really helpful. The impact on accessibility is not that great, if not negligible (ask the experts) if you do it right.
It’s not a bloody stupid idea either to use float for putting blocks side-by-side, even though that property was not actually designed for such use.
I don’t see why using display:table and display:table-cell for just what they’re meant for (since 1998) would be more stupid. :D
Of course, this is an approach for layout tables only. Actual data tables must remain tables, and should use real data table markup, which is highly semantic: throwing those semantics away by going to anonymous divs would be completely the wrong thing to do!
very gradually! IE6 still has a market share of about 30%, and usage of Windows XP (which comes with IE6) is on the increase due to the fast-growing popularity of small-screen netbooks.
I rather expect a trickle of change.
We really should have had this years ago. The specification was written 1998, and here we are ten years later waiting for them to get it right.
Expecting MS to release a bug free standards compliant browser is the real pipe dream.
What else are we going to have to put up with in this release? I’m guessing that being MacGyver is going to still be a necessity.
[…] Speaking of, the Vitamin piece “Tables: The next evolution in CSS Layout” compares Web designers to modern-day MacGyvers. […]
[…] Tables: The Next Evolution in CSS Layout […]
The notion that designers, or developers as I would label them, would prefer tables over CSS because of simplicity is reflective of a poor and lazy developer. The cost of semantic and meaningful CSS layouts versus table layouts is a price any good developer would gladly pay. If you think other wise, I invite you to head on over to myspace.com and inspect their code - there is no meaning from one table to the next that would offer any hint of the content it contains.
The prospect that IE8 would finally offer the full support for CSS tables already seen in other browsers is fantastic, but as others have said, this isn’t the 2nd coming of Christ people play it out to be. Market share of IE6 and IE7 are still far too high to be counted out.
The tone I get from this article is as follows. CSS layouts are too hard. Regular tables are easy as cake, but lack support in IE. Therefore since IE8 is coming out, CSS Tables are the best choice.
I would argue that although CSS layouts may be tricky to master, once you do they offer the flexibility and meaning that tables can’t measure up to. Tables have their place - reserved for tables of data, sitting quietly behind the magnificence that is Cascading Style Sheets. And as for CSS Tables, they will still be second place behind floated and display:block elements handled via CSS.
I honestly don’t see how CSS Tables solve any problem at all. So instead of having a bunch of TDs there’s going to be a bunch of DIVs? Great, thank the lord. The world of web development has been saved.
Except, how are a bunch of DIVs anymore semantic than a bunch of TDs???
It’s perfectly possible, straightforward even, to design top notch web sites using existing and supported CSS and HTML. The real problem is web designers who don’t understand the medium they are working in.
[…] Vitamin Features » Tables: The Next Evolution in CSS Layout (tags: webdesign tutorials tables css3) […]
tables are for bitches
[…] Selon l’auteur de l’article “Table : la prochaine évolution dans la conception css“, l’apprentissage du css et de la structuration serait facilitée par l’utilisation de propriété css visant à reproduire le schéma d’un tableau. […]
You’re been voted !!
Track back from http://webdevvote.com/HtmlCss/The_Next_Evolution_in_CSS_Layout
Tables still have an important place in HTML though. They have the right to be on any page where they will actually display tabular data.
In those cases, however, I think most people forget about making them semantic by leaving out important tags like tbody, caption, th, etc. that give screen readers context for understanding them.
So while I wholly agree people shouldn’t be using tables to do layout in 2008 and beyond. They should have stopped in like 2002 when most browsers had at least marginal support, albeit with hacks, for css layouts.
I firmly believe that tables are a critical part of the web for displaying tabular data. When used in that context they work very well.
…so many professional designers still choose to use HTML tables for layout.
They do? Who are these people, let me at them. I am sure I may be proved wrong with a host of examples, but I am incredulous that there are “many professional” anythings using HTML tables for layout.
The future eh! time to get playing with this then.
I think that using tables again is not necessarily the solution a lot of people will never up grade their browser, there will always be the people that click off when they are told to upgrade. I know that as people buy new computers then they will download the new version. I think the most important thing is consistent creative design over all browsers and that is currently not an option.
This sounds good for overall master columns and I hate using ‘float’ in css. It usually screws something up somewhere…then I have to think about absolute positioning. So I can see how this will be helpful.
BUT I agree with everyone on here that mentioned it may encourage bad practices of slicing up images like in the old table days. I think if people use this for overall grid/column layout, it’ll be good. But the minute the ‘table’ css starts being used as a container for every page element, I think that’s not going to be good css design (and I’m sure it will happen).
[…] […]
In my website I injected the table layout with JavaScript: http://www.cromoteca.com/en/blog/tablebasedlayoutswithsemantichtml
[…] So, some guy over at Vitamin has a new radical method of designing for the web – Tables! Don’t worry, it’s not really as bad as it sounds. The general idea is to replace those awful table layouts with semantic markup, and use CSS to make them behave like tables, which is perfectly acceptable. Now, up until recently this has been a bad idea due to the fact that Internet Explorer apparently didn’t support the table display modes in CSS. Version 8 of IE will, however, so in the future designing might become an easier task, at least when it comes to multi-column layouts. Now, I’m not entirely sure that a multi-column layout is the best way to go, I actually prefer single-column layouts as well as radical, innovating ones, but the multi-column layout has proven to be successful so far. The question is; was this because it’s a good layout – or because it was easy to implement using tables? But I digress… the point is, doing stuff the easy way sometimes supresses creativity, and we have to ask ourselves – is this a good idea, or is it just regular tables all over again? […]
[…] Tables: The Next Evolution in CSS Layout Vitamin Features (tags: css) […]
I have always liked the new css-table properties and after reading this article I think i will be using it more often. The only issue is the ie browser, but this can be easily fixed, see my suggestion at: http://oguz-karadeniz.blogspot.com/2008/12/tables-next-evolution-in-css-layout-is.html
At the end I think it is matter of choice by the designer/developer to choose what way would be the best, but from my perspective CSS tables make life easier for me.
[…] Read Tables: The Next Evolution in CSS Layout […]
[…] Tables: The next evolution in CSS Layout - Kevin Yank van Sitepoint bespreekt hoe CSS tables layouten met CSS een stukje makkelijker kunnen maken Print This Post […]
[…] December 31, 2008 Posted by shahriarhaque Filed in Gaming […]
[…] http://www.thinkvitamin.com/features/css/tables-the-next-evolution-in-css-layout […]
..and jetpacks! oh and you forgot about teleports and vacations on the Moon. Beam me up Scotty!
..about 20% of visitors of any of my sites still use IE6 and this won’t change in the next year or two. And then there’s IE7 - another 30-45%, another couple of years to get those folks to use IE8.
So yes, very interesting stuff, but I wonder if the polar caps won’t melt before any of the stuff you’re writing about becomes real.