CSS vs Tables

When I started exploring the design possibilities of the internet back in 1996, NetObjects Fusion was (at that point) a revolutionary WYSIWYG editor that allowed you to place pretty much any components anywhere you wanted on the page. Unfortunately for Website Pros, Inc. Macromedia had also seen the potential in WYSIWYG editors and developed what is arguably the most popular web design tool ever – Dreamweaver.

Dreamweaver has managed to keep up with the requirements of the modern day web developer by constantly updating and improving aspects of its design, layout and functionality. With the latest release of Dreamweaver, Macromedia have again improved on various features but have also come to realise the potential and the need to support (in more detail) the new designer’s technique – cascade style sheets (CSS).

Having always designed using table based layouts, I recently (less than 3 months ago in fact) decided it was time to look in more detail at CSS, to learn what it could do to improve the quality of my work, specifically in terms of positioning and layout of website elements. At that point I already had a basic understand of CSS and how to use CSS to influence text styling, link styles, table colours and borders etc. The challenge was (more clearly) to see if designing layouts using CSS instead of tables was (to me) easier and more beneficial – could I be persuaded to change despite my dedication to tables?

My choice of two books (which I’m still reading incidentally), are both written and published by Sitepoint. The first (The CSS Anthology – 101 Essential Tips, Tricks & Hacks) is an excellent practical guide, not only for beginners but also for people (like me) wanting to learn a bit more (or in fact a lot more) about the potential of CSS. Whether you want to know how to justify text, create a pure CSS drop down menu or implement a liquid, two-column layout, this book is an excellent start or continuation for anyone interested in CSS.

The second and probably more relevant book that I chose (again by Sitepoint) is the 2nd Edition HTML Utopia: Designing Without Tables using CSS. This book again goes over the basics of CSS, but in a more concise and brief manor. The main bulk of the book concentrates on more examples of positioning and layout. In short these are two books that I know I’m eventually going to read from cover to cover – two books that will always be to hand and provide the answer to my question when something goes wrong or I don’t fully understand exactly what I’m doing (something that happens on a regular basis).

So what have I learnt in the last few months from reading these books, reading relational website articles and listening to peoples points of view on webmaster forums? Quite simply I was quite stubborn in the beginning. I had tried about a year ago to use CSS for layouts but hadn’t got very far (although at that stage I had no books to use for reference). This time around I had the knowledge (or more accurately the books of knowledge) but was already expecting my own personal failure (based on my previous experiences). Luckily though I stuck with it and now know a lot more (although obviously not everything, by a long shot) about the potential of CSS.

Obviously (just by looking at my site) you can see that I have indeed changed from table based layouts to CSS layouts – but what truly changed my mind and would I ever go back to tables? Is this site simply a one off?

Tables were in fact not originally intended to be used as layout tools – expert designers (especially in the beginning) discovered that they could use tables, within tables, within tables to create and position quite precisely most (if not all) web page elements. The major problem and issue with this method (which has been emphasised even more so in recent years) is using this method to produce standard compliant web pages.

Tables, nested again and again and again result in load times that are longer than necessary, encourage the use of inefficient ‘placeholder graphics’ that further slow performance, cause major issues for web page maintenance (even when simple, minor changes are required) and can often cause the page(s) to become inaccessible to those who are not using a graphical web browser. CSS in short overcomes all these issues by separating content from code.

The intended purpose of tables is in fact to display tables of data – something that CSS gurus are constantly quoting in web forums and web logs. This is highly understandable when you accurately understand how tables work and load within a browser. Web browsers are deliberately designed to ensure that each table downloads as a single entity. None of the material that is contained in a table will be displayed until all the contents of that table are downloaded to the client machine and available for display. In complex designed sites where lots of nested tables are used it is quite easy to see how this problem can effect the load time of web pages – in addition to the apparent delay in load time there is also the issue of the sheer quantity of HTML code that’s required to create each individual web page. Table-based layouts almost certainly account for more user concern over long page-load times than any other single factor.

Another major issue that I am all too familiar with is how ridged tables can be when trying to create a visually appealing site design. I am a designer who likes everything positioned in a pixel perfect manor. It has often been the case where additional room has been need above or below a certain table element to allow the design and content to ‘breath’. On conceivable method around this problem (as any table layout designer will know) is the use of a transparent gif image, a tiny GIF image that has no visible content. By creating table cells that contained these transparent images, additional space (either vertical or horizontal) can be added to achieve the required appearance that the designer requires. This solution in itself can and does cause major problems. Given a table with dozens (or even hundreds) of these transparent type images, the performance impacts of transparent GIFs on a web page can be significant. More importantly though, this technique often restricts the page to a fixed pixel size and clutters the page with images that are irrelevant to the meaning of the page content.

Combine all of the above with the additional complex and problematic ability to maintain a complex array of deeply nested tables and you’ll find even with tools such as Dreamweaver or Adobe GoLive that you’ll soon be tearing your hair out or getting the undying need to throw your computer out the window!

Finally tables are bad due to their inability to be correctly viewed by none graphical web browsers – such as the screen readers used by many visually impaired users. When a text only device reads he content of a site, it starts at the top and works down the page line by line. When it comes to a table, it starts at the top left and works left to right, row by row. For obvious reasons when nested tables are used to display chunks of text in the desired layout, that content can become nonsensical when read in this manor.

So would I or will I go back to table based layouts? In a word no! Not only does cascade style sheet layouts allow faster load times and better accessibility to people with disabilities, but it also allows me to create and design accurate cross browser enabled websites. I can position elements and components exactly where I want and can easily separate content from code!

The principle of CSS is thus:

The World Wide Web Consortium, better known as the W3C, saw that separating the content of a site from its presentation (or appearance) would be the most logical solution of future web design and development. This technique would enable content experts – writers, artists, photographers and programmers to provide the ‘stuff’ that people come to a site to see, read or experience. It would also free the design experts – artists, graphic designers and typographers to determine a site’s aesthetics independently of its content.

The result was CSS.