CSS better than tables! Really?
It's almost a year since I last talked about CSS and tables. Back then I was missing the days when we used tables to layout our designs. I still do!
As a web designer a year is not a long time in the scheme of things. Nothing much has changed. Designing with CSS to support
I've just finished designing a site where the requirement was for it to be a CSS-based layout, to work on AMBAP, including both Mac and Windows. The design was simple: left-hand navigator, header, footer, fixed-width etc etc. If it were a table it would be three rows and two columns. Easy peasy. With CSS it might be fairly simple to get a bare-bones layout knocked together, but it all falls apart once you start adding more styled objects inside each part. Bits go missing, fall off the side of the page or act all strange. The price to pay for being semantically correct (whatever that means)?
What difference does it really make though? Well, here's the HTML for the equivalent table:
<table width="760"> <tr><td colspan="2">Header</td></tr> <tr><td width="180">Navigator</td><td>Body</td></tr> <tr><td colspan="2">Footer</td></tr> </table>
And for the same page in CSS:
<div id="Container"> <div id="header">Header</div> <div id="navigator">Navigator</div> <div id="body">Body</div> <div id="footer">Footer</div> </div>
In terms of the amount of code needed there's not much in it. Although, with CSS, we need the actual style definitions so that makes table-layouts lighter in this case.
An argument for CSS is that it makes it easier to change the layout of a page further down the line. Well, if you use a modular approach and design cleverly there's no reason pages that use tables can't be just as simple to modify.
The crunch for me is that to create this layout in CSS requires some ugly hacks! There are so many bugs in the behaviour of the different browsers that it becomes inevitable. With this site I was glad I managed to arrive at a design that didn't need any. With the current site I am working on I found myself using a hack to hide styles from IE5 on the Mac as well as a hack to mimic min-height in Safari.
The worst thing about these and other hacks is that they work now but aren't guaranteed to in future releases (although there won't be any future version of IE for the Mac!). You end up selling your client a ticking bomb, weighting to go off in their face.
What I'd like to do is use tables at this high level and only this level. Use a table to define the high-level layout of the page. Nothing else. No nested tables. No tables whose code you can get lost in. Just a few simple rows and columns. Every other styled element on the page will be controlled with CSS, thus keeping HTML code to a minimum.
What's stopping me? Well, in this case, the wishes of the client and, in general, peer approval. There's a certain amount of snobbery in web design and I sometimes want nothing more than acceptance. Still, if it weren't for the idea of being able to view the source of websites, I'd be have gone back to using tables long ago. While I see the reasons for using CSS I just don't like using hacks and still not knowing it's going to work as expected. Until CSS is reliable enough to do what I want I'll always find myself looking back to the days of tables.
And finally, a massive thanks to Joseph P. Kenney, who I can find no other way of contacting. He knows why.
*AMBAP=As Many Browsers As Possible, which I just made up. I wonder if I can get it accepted as a new webby acronym...
Skip to the 
You can subscribe to an individual
I think that CSS really missed a huge possibility (this actually Ned Batchelder's idea) -- the possibility of defining a table in the stylesheet. A normal table, just like you'd use in an HTML document (not the ridiculous table-cell-appendage crap they've actually given us). Just do a table and attach your layout-neutral, semantically-correct HTML to the table by putting an id into a cell.
I've been pretty vocal about semantic markup since there was no choice (pre-Mosaic), and I'd like to see things as close to the ideal as they can be. It's a bit of a bummer that browsers force us to lie about our content in order to acheive a layout, and a bigger bummer that no-one on the CSS committee was able to figure out that "extend this all the way down to the bottom of that" would be something we'd kinda like to have built into the system.
A technique I use to avoid using kludgy browser hacks is to put all the normal css in one stylesheet (basically design in moz/ff) and then put the additional code needed for the other browsers in separate sheets (ie.css, ie5, ie55, etc).
Then I use some other method to detect the browser type/version and then include those sheets required, avoiding javascript if possible.
If coding in straight html, you can use conditional comments (IE only) {Link}
I found a great php script for browser detection (can't remember off the top of my head), and I recoded it for asp.
One thing to watch out for is that IE's conditional comments won't work if you're using the multiple versions of IE trick {Link}
Jake, I couldn't agree with you more!
Jake,
This is a good point. For content-based websites I think using web standards code to layout the page should be possible.
But with web applications (which is what I spend 95% of my time doing), it becomes extremely difficult to lay the screen out using css.
There seems to be no simple equivalent to a table (width 100% height 100%) with a fixed width navigator and then a cell that sizes to the rest of the screen - height and width wise. It's the height that seems to be the problem.
With a content based site this doesn't matter as much because the page only needs to be as long as the content anyway...
Dorian
I agree, it can be very tricky. I am writing a big web app at the moment. Laying it out isn't too difficult, but getting everything to scale the way I want when the screen is resized is very demanding.
I nearly switched back to table layout - which gave me everything I wanted - except for the fact that IE and FF do weird things to IFrames, which are embeded in tables, when they resize.
The best answer seems to be a combination of css and javascript to deal with onresize events.
Andy B
I think one point about tables were the nested table monsters that were around the web. The table structures itself were pure art as one missing td tag would have had the power to destroy the whole design and the code itself was a horrible table tag soup. I still use tables but just for the basic layout (if applicable). That means 1 table for the page with a few rows and normally not more than 3 columns (something like your example).
I use pure CSS for the rest. I am quite happy about this approach as it saves me lot of time but I am not a web designer anyway.
I have just waited for somebody else to react on this web design snobbery.
There are lots of sites speaking about usability, and of course it is important that as many as possible can access the content, but do we really have to reach all?
It is also important that the code does what it should, and that it is understandable for more than the creator. But must it be perfect like a master painting?
I think you should use what is effective and has a reasonable level of finesse. I understand the joy of creating a great dynamic page that scales in all directions, but do we need it? It must be the value of the information or service contained that is the most important matter.
Simple is beautiful.
Let's put some points over:-
1. Fredrik, web design snobbery is one thing, but if I was using a screen reader I'd really rather you made your site accessible - so please do try to reach as many as possible. Due to recent changes in the law, your client may have a legal obligation to do so.
2. Tables are not inherently bad, but they are often a barrier to accessibility. The keys are handling linearisation and keeping things simple (see {Link}
3. CSS-based layouts are tough when your target is AMBAP. I wish someone would publish some layouts in an Open Source type setup. We could then subscribe and help maintain them!
Hi Jake,
I understand your difficulties, but the fact is that tables genuinely do cause accessibility problems, particularly for screen readers (as Arka has mentioned).
I've designed a number of web-sites, and yes, even Domino apps, using CSS entirely with no tables, and it can be done!
It's a real pain in the a*se, and takes a lot longer than using tables, but isn't that applicable to learning anything new?
Every new technology that comes along has a learning curve, including CSS, but sites and web apps can (and should) be laid out using CSS.
Another factor about semantic markup and CSS of course is that we're not just talking stylesheets here, we're talking about changing web-sites to use XHTML as well as CSS - so that they work on ALL of the next generation of browsers. The whole idea is to standardise how pages are coded so that browsers don't have to be designed to allow for quirks and proprietary tags. It may not be the case now, but XHTML and CSS will actually improve browsers too - look at Firefox.
Sorry for the rant, but I think sometimes in the talk about CSS and avoiding tables, we all forget some of the reasons we do it. But it can be done, and it gets easier eventually!
One more point too, is that for browsers like IE5/Mac, you can use some tricks to hide/show styles from the relevant browsers, that won't cause problems later.
For example, Tantek Celic's mid-pass filter allows you to deal with IE5/Mac in such a way that a.) no scripting is necessary, and b.) won't affect future or past browsers other than the one you want..
{Link}
"and a bigger bummer that no-one on the CSS committee was able to figure out that "extend this all the way down to the bottom of that" would be something we'd kinda like to have built into the system."
Here here!
Because of this... I tend to use a combination of tables and CSS layout for my sites. Elements aligned vertically get the CSS treatment. Elements aligned horizontally get the table treatment. My sites tend to look like this...
<div id=header>Header</div>
<div id=body>Body</div>
<table><tr>
<td id=sidebar>Sidebar</td>
<td id=content>Content</td>
</tr></table>
</div>
<div id=footer>Footer</div>
If CSS gave me an easy way of increasing the height of a sidebar to that of the content, I'd be all css.
Recently, however, I'm tending to develop sites that don't have any background or border elements on the sidebar... which can pretty much eliminate the need for this. Still... when I need to... why can't we get a css layout that just works.
Here, here, Jake.
Many of us the corporate world have spent the past year painfully re-working our design processes to follow the Sarbanes-Oxley Act "way", and it occurs to me that stylesheets fit into that way quite nicely. "You can't touch this" is our new battle cry, and stylesheets mean we can change the design site-wide and from a safe (according to SOA) distance without going back into the application and changing the ever-lovin' code itself.
I feel your pain, man. CSS is kind of like a home-cooked meal - it's better for you, but it takes a whole lot more effort than ordering take-out (i.e. whipping out those table rows and cells.).
Thanks for not shooting me down guys.
I understand the accessibility argument to CSS and know why it's the over-riding factor. My complaint is that they expect us to use CSS, yet it's not truly up to the job.
Karen. I like your analogy! I have a great one to share some time soon, where Domino is an F1 car and I'm Michael Schumacher...
I enjoy using css but do miss tables every now and then. Using the method described on this page --> {Link}
makes me feel like things are moving in the wrong direction. However creating a seperate print stylesheet is absolutely wonderful. I try to keep the layout simple which usually eliminates the need for hacks but of course they are employed when I'm unable to sell the "why". As always, keep up the good work.
In the last year, I've really turned around from a table-boy to a CSS-wannabe.
It's really the fact that reading HTML without those horrid nested tables is a lot easier eg. when trying to track down bugs/errors. Also, I find it a lot easier to change this along the way - the table structure was just too rigid in the end - with CSS I can hide, adjust and move elements around the page.
I've been giving the job of migrating some sites over to our Department, and with 3-4 levels of nested tables, suddenly CSS looks very attractive.
Yes, hacks are a nuisance and a worry for future compatibility, but any change whatsoever to a nested table layout is downright dangerous.
Plus, there are so many CSS resources out there nowadays that you know that every problem you have has already been solved.
We're doing our utmost to use CSS where possible and only use tables where the data requres tables, or something we call a layout table when the users are entering content and want to use a table to create layout columns. We try and avoid this.
We use all sorts of horrible code to ensure that CSS column 1 is the same height as CSS column 2, regardless of content. As I guess others of you have found, telling a user we have to stop using tables and use CSS instead, and by the way we can't ensure the columns are the same height any more didn't go down well at all.
CSS is very powerful, but as I'm finding today, trying to change something in a cascaded sheet without changing other things is doing my head in. I just can't see the wood for the trees!
We develop for an intranet so are meeting only 1 browser which solves some issues you other chaps have of coding for AMBAP. Good acronym, Jake!
Caroline
Can I start by saying that I know very little about screen readers.
That being said, it would seem to me that if screen readers have problems with tables within HTML, then would it not have been a better idea to improve the screen reader software to fix this as opposed to outlawing using tables within HTML?
It just seems stupid to switch to CSS, when it doesn't render web pages the same in any two browsers.
If developers are going to be forced to use CSS instead of tables then shouldn't CSS at least be consistent accross all browsers!
Alex
Hi Jake,
I've been in the CSS no table design for a while and yes, styling the right layout for any browser is a "pain in the arm".
I laughed a lot with your F1 analogy, and if you do some research you'll see that as I'm chilean, if Domino is a F1 car I should be Eliseo Salazar.
Ouch!
:-S
.::AleX::.
Well, I'm Canadian, but if I were to put myself into the F1 anology, I'd have to say that I'm more of a Zsolt Baumgartner. Still, I can understand full well why screen readers can't attach proper meaning to layout done entirely with tables, and why no attempt to "improve" the software is going to get around the fundamental difficulties.
Apparently Alex (who is so famous he need not have a last name) doesn't realise how much intelligence goes into deciphering the written word -- how our perceptions are shaped by experience and convention, and how adaptive humans are when assessing the visual design of a page. All one really need do is take a look at a few of the "cutting edge" magazine designs out there, where normal font, case, decoration and colour expectations are not met for artistic reasons. One actually needs to school oneself in reading these things. If there is no formal connection between design and meaning (something that semantic markup and CSS does that tables cannot do), then asking a computer to convey the meaning of the content to someone who cannot see and interpret the visual cues is asking an awful lot.
Table-controlled layout is a BAD THING, and should be avoided. Unfortunately, in many cases it CAN'T be avoided without degenerating the graphic intent of the page.
Here is the text from IBM Lotus Workplace Content Management Product's Info center ( User Guide -> Page Design ->Page Layout )
Do you think Lotus suggest' use of Tables over CSS layout ???
"This is an example of a possible layout of a Page Design. Although it is recommended that HTML elements (such as tables) be used to specify the exact layout of a Page Design, you do not have to use them."
If you've never heard your website, I'd highly recommend downloading a trial version of a screen reader - it's really quite something.
Call me easily entertained, but I got a kick out of hearing the electronic voice read my homepage. But beyond that, it gave me a greater appreciation for what sight-impaired accessibility is all about. Screen readers rock!
IBM has a trail, located here:
{Link} (43MB)
And JAWS(R) is also available:
{Link} (see the link for the free demo) (40MB)
Hi.
I think the problem is not CSS but bad implementation of standards of a lot of browsers ... The horrible competition in the War of Browsers ( Microsoft vs Netscape ) did a lot of damage to the standardization of Web technologies.
It's true that CSS must be improved to support best the columns model and other things that now we have to do with a lot of tricks and hacks. This tricks and hacks in CSS scare to web designers that prefers do the layout with tables instead of using CSS layout.
I'll bet for CSS. I think it's the future: Separate the layout from content ... and semantic HTML.
Regards.
(Sorry, i'm spanish and my english is .... bad ... very bad )
I totally agree. I've think I've said it before on this site, there is so much snobbery about using CSS. I believe that there is a sensible balance - do layouts in tables, but apply styles to tables and parts of tables so that you can easily update the look and feel (and dimensions and contents). That's how I do my site. Admittedly it would take a lot of work if I wanted to change the overall construction of each page, but for changing the look and feel it would be dead easy (I've already proved that to myself when working on the new design).
Plus, it seems to be fine in all browsers (the photo album doesn't work in Safari but that's a script problem). It's just the content that's rubbish ;o)
Uh, that's not the point of CSS. I consider tables (other than when used to contain actual tables of data) a hallmark of failure. Not necessarily of the developer but of the system as a whole. Semantic markup and CSS isn't about snobbery (well, not usually, at least), it's about meaning and (most importantly) accessibility. Styled tables are still tables, and still lie about what they contain. That makes no difference to people who can see your page and don't know about the tables -- but it makes a heck of a lot of difference to people who can't see your page and therefore have to rely on the markup to tell them what's there.
I quite agree, Stan. Using properly coded pages to allow everyone, including the partially sighted to access a site, is good. As a sighted individual I can see where the headings on the page are at a glance. How does a screen reader know where the headings are to read them to the user? It looks at the HTML tags h1, h2 etc. It can't know that a table is being used for layout and will be looking for TH tags to see what the cell's heading is. Which won't be there as the developer has only used the table for layout, not tabular data.
It's been hard work getting my head around why we should/ should not use tables/ css etc. but it's been very worthwhile. I think as a result I write better, more portable code, and I know that things are much easier to change when the users mysteriously want to change the colours scheme at no notice etc. Once you know how you have written your stylesheets you only have to remember which divs and spans to use round your content and bingo! your page is exactly as you wanted without having to remember how wide column 1 is supposed to be or what the hex value is of the background colour of something. In my conclusion, CSS is relatively little known, a little tricky to initially master but so so versitile and powerful, and also much more DDA compliant than using tables for layouts. Our company is really big on getting things DDA (Disability & Discrimination Act) compliant.
So CSS doesn't work the same on all browsers etc. Well I can't access my online banking via some browsers. These things might be irritating but they are here to stay and in any case keep us on our toes.
No contest - CSS v tables is a one horse race. Unless you are trying to display tabular information in which case it's still a one horse race, just the other horse.
CAroline : )
Her we are all discussing about if tables are better than CSS , again.
I think that a great amount of you, people, work with IBM technology, Lotus, WAS, CM, etc.
If you need to create a business application and you should follow the IBM example in almost all of their workplace, domino and was examples and even business sites
{Link}
{Link} --> emergin technnologies. what!
Tables, tables, tables, tables, tables. It looks like a HTML restorant.
.::AleX::.
HTML restaurant... that's funny!
And I have to say, my homepage contains tables but the screen reader reads it off exactly as intended (goes through all of my left nav links, then to the main content, then to the footer content - pretty much how my eyes traverse the page in my opinion).
I'd be interested in accessing a website using the screen reader and hear a "messed up" page due to the use of tables - if anyone knows of one. Not for the purpose of argument, only to better understand.
This is a good article which briefly covers why tables shouldn't be used for layout, and also where and how they should be used.
{Link}
Karen -- all it takes is something as simple as field labels aligned with fields using tables alone. Or, for that matter, any metadata (labelling, sectioning) not strongly associated with the intended content. A screen reader may parse the text in the correct order, but it's missing the association between the label and content, so it can't tell the user what field they're currently in and so on.
Admittedly, the better readers give it a valiant effort, but since there's no guarantee what the alignment between field and label, say, will look like, this is a hit-and-miss venture at best. That's the problem with relying on tables for layout -- the developer/designer tends to use them to the exclusion of semantically-oriented markup options. Visually-impaired users (like the rest of us) would also like options to quickly scan a page for relevant content. If markup is entirely presentation-based, that's really, really hard to do.
Excellent article, Lee. Between that and Stan's additional comments, I think I've "got it". Thank you.
Jake, here's to CSS becoming as "easy peasy" to code (and execute) as the simple html table. And I will ALWAYS frequent your blog, whether it's an html restaurant or not! (laugh)
Glad you liked the article Karen. The great thing about CSS is that there are so many sites devoted to it, and blogs which cover CSS (like 456 Berea Street) that you can get answers to pretty much any question. I use sites like these all the time - the same as using Jake's site for learning new things about Domino!
Jake, are you convinced yet?
>>Jake, are you convinced yet?
Lee. I don't need convincing. I doubt I'll ever use tables again. I've been a CSS advocate for years now and haven't used a table-layout for about 3 years. My gripe is that life was a nightmare using tables to layout pages and it *still* is now that I'm using CSS. Must be age, I'm getting less and less patient with other's mistakes.
PS: Is that you on the Duvel? You want to be careful with that stuff!
Ha ha, certainly is!
i've stayed away from the stuff since Christmas, I had a Duvel gut...
Stan, you seem more concerned with my surname and having a go than actually understanding my point.
What I was saying was that if CSS is to take over from tables in html then standards should be put in place to make sure CSS renders the same in all browsers.
As I also said in my post, I know very little about screen readers. Didn't you read that bit before you went on a rant.
You seem wound a little too tight Stan, perhaps you need to chill a little instead of having a go at people expressing an opinion that you don't agree with.
Alex
Alex,
I don't think there was anything malicious in what Stan was saying, he was just pointing out that screen readers rely on us humans putting pages together correctly.
If you haven't any experience of one the best thing might be to download IBM's HomePage Reader, there's a free trial on their site somewhere and it's really strange to have one read out your site to you!
But your point about putting standards in place to make CSS work is misunderstanding the point. CSS and XHTML are the standards, the problem is that browser makers are still catching up.
The W3C have developed standards for how CSS should be rendered, but most browsers still differ in how much of these standards they choose to implement. But on the positive side, Firefox implements standards well, and IE6 is a massive improvement on IE5, so there is hope!
In my opinion the table-tag is dualistic, it's BOTH structure and content. Hence, there is really no reason why you shouldn't use it for page layout! The point is not to mix up the two types of "tables". Unfortunately, that's exactly what the inventors of HTML have done, creating just one tag for a dual purpose. Using a grid-type layout for web pages is not bad, it's advisable! If you want a strict grid-layout it's not very wise to try to "emulate" the grid by using a lot of blocks.
As Stan mentioned, this has previously been discussed at Ned Batchelder's blog. The solution could have been inventing something like a grid-tag to take care of the grid layout, reserving the table tag for content with a matrix data-structure. I'm not very optimistic...
Alex,
Stan's responses can come across as somewhat ... er ... colourful. But then, he's had a colourful life - see {Link} for an interesting insight.
Having said that, I must applaud Stan for his stance and responses on this topic. I think we all need to be more aware of the rift between the experience of sighted users and those using adaptive devices. It's encourraging that so many here appear to appreciate that.
I think CSS is up to the task it's intended for.
It's the browsers that aren't up to CSS, that cause the problems.
Until the browser makers all get on the same sheet of code, and produce products that meet the CSS standard in way that compliments one and all, CSS will continue to have it's cross-browser quirks.
I can write no-tables CSS code that works in IE And Opera, but fails in NS, and the only way to make it work in NS is to make it fail in the other browsers.
Personally, I can do without NSnav.
I've never seen a version of NS that I liked.
IE has market share.
Opera is just too good, it's too user definable, as such most users can eventually find a way to render your page unreadable; Although they might be impressed with the amount of effort it's takes to do it.
Bottom line; Does the site do what it's made to do, for the people it's supposed to do it for?
I can remember when the www was nothing more than series of text-based bbs's with black backgrounds and mostly green text, and it got the job done.
Are tables really that bad, is CSS the only answer?
Probably not.
Rest assured though, as soon as we get a good handle on CSS, and cross-browser-compatibility(CSS-CBC), somebody will come along with something even better that has even more bugs in it.
The way I see it, if it works use it, if it doesn't, it's useless.
Don't get me wrong; Accessability is a good thing for those who are visually impaired.
On the other hand so is Accessability for the visually capable.
Two very different groups of people there; However, they do have the advantage of only having to rely on one browser to correctly display their sites of choice, and no doubt about it, if one doesn't work they'll find another that does. Browser that is.
I don't know about you, but I'm going to go with the browser that supports the best code, and let the browser makers work to get my business.
Like I said above, I'll code for IE and Opera, and to hell with NS.
I often ask myself this. Why oh why should I spend hours, days & weeks tweaking css code to get a layout act as one would like when dealing with dynamic content. Why couldn't we just have min, max widths and heights on divs.
Imagine this: A 3 column layout with a top and a footer. All with dynamic content that I cannot know the size of beforehand. Why in the name of all gods is this so bloody hard to achieve in AMBAP without resorting to the aboniable table layout. A lot of customers whant the pretty sidebars with their nice background image/colour to stretch all the way down to the footer (not beyound, not somewhere above). Using a table it's a snap. Using all divs & css it's a great pain in the rear end. If one could use css without future-unsafe hacks it would be a blessing. But since most customers want both pagereader compatibility and pretty layout of all pages with all types and sizes of content were bound to have nervous breakdowns.
Why dont we (all frustrated webnerds) get a list of names to add these small additions to the css standard, and get the browser manufacturers to agree that this is a good thing and adhere to it.
thank you for rading and good day.
Im failing to understand how nested divs is better than nested tables.
<table>
<tr>
<td></td>
<td></td>
</tr>
</table>
<div id=contatiner>
<div id=sidebar>
</div>
<div id=content>
</div>
</div
How is this better?
Tables, when coded properly (each table including a summary tag for example) are NOT a barrier to accessability. A good screen reader combined with a well and neatly programed table based site will have no problem grabbing the content.
CSS positioned div's are an ideal, much like communism, that work better on paper than in practise. Tables are not broke, there is no reason to fix them. Tables render very consistently across browsers and are very likely to continue to do so for many many years.
You can't say the same about CSS Div's.