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.

Written by Richard MacManus

Sometimes when you talk to a professional web developer you'll hear the phrases 'CSS layout' and 'Tables Layout'. Without knowing something of the history of web development these phrases would be meaningless to you which is why I'm going to talk about them today as they happen to be quite important.

Back in the mists of time there was HTML. HTML was the basic programming language used to create websites and since there was only one major web browser on the scene all web pages were built in HTML to look good with this browser. Because HTML was young and basic the best way to achieve complex layouts was to use something called the table tag. The table tag was very flexible and allowed the programmer to create tables where each table cell contained text or graphics or both. With a bit of ingenuity, patience and imagination, increadibly complex designes could be built using this method.

But as time went on other web browsers became popular and each had subtly different ways of 'rendering' the HTML and tables. Because the browsers were in competition with each other they each added different features and extentions which were not part of the official standards and the rendering differences between the browsers grew greater and greater. Problems also became apparent with maintaining sites with complex table layouts and browsers for blind people (commonly called screen readers) had major problems disiphering and distilling these sites in a meaningful way. Eventually, the 'Browser Wars' as they were known back then were won by Microsoft and its Internet Explorer browser. This had the effect of killing innovation dead and for a while we were left with horrible table layouts and bad standards support.

To present day
When it seemed all was lost a number of crucial things happened. With its dying breath Netscape (the other major player in the browser wars) won an Antitrust case again Microsoft. This had the effect of creating enough breathing space in the browser market for competitors to re-appear and three new browsers began to gain a foothold, Mozilla's Firefox, Apple's Safari and Opera's Opera browser.

At the same time the standards organisation W3C (World Wide Web Consortium) began to re-assert its authority in the face of calls for better support for screen readers and disabled internet users. This new round of standards were called Cascading Styles Sheets (CSS) and xHTML and were aimed at providing a more descriptive way of building complex web layouts without sacrificing accessiblity, effectively allowing developers to totally separate content from appearance.

This provided a common cause for Microsoft's competitors to champion and before long the only browser not doing CSS and xHTML properly was Microsoft's Internet Explorer. Microsoft finally stared to fix this deficiency with IE7 in 2007 and they promise to be fully compliant by the end of 2008 with IE8 but its taken a 15% drop in market share for this to happen.

Thanks for the history lesson but what does this mean?
So thats the history but what does it mean to you? Well, as you might have guessed its common opinion that CSS/xHTML is good and that Tables and HTML4 is bad. This is for several reasons:

• CSS/xHTML when done right will be more more accessible to people with disabilities
• Because CSS/xHTML is a rigidly defined standard, your page should always look the same across standards compliant browsers (providing its built correctly)
• Theoretically it should be easier to completely change the appearance ofa CSS/xHTML website without modifying content or the actual webpages thus making CSS/xHTML site much more maintainable.

So why do developers still do table layouts if CSS is so great? Well its a complex issue, many developers have learned their Tables skills through years of hard work coaxing the different browsers to do the right thing. CSS is a fundimentally different way of building websites and as such Tables based skills are next to useless. Busy web developers are understandably reluctant to throw away their hard earned skills and start again, this costs them time, money and possibly reputation as they re-learn their trade.

Fine you say, if its so difficult to change then why cant we just have both? The problem here is that because the two approaches are so different from each other, if a site is built in Tables in this day and age it is already effectively obsolete and will NOT be maintainable in a couple of years time. Right now all new sites should be being built to the standards, this will help Microsoft and other vendors make their products more standards compliant which in turn will make life easier not only for web developers but for users with disabilities and ultimately for all of us.

What should I do with this information?
When deciding who you want to help you build your new website make sure you ask them if they build in CSS or Tables and if they answer that they use CSS then ask them to show you a site they have built that validates. A validator is a tool which examines a website and checks for errors against the standards, ideally a website should validate but if it fails on minor errors its not the end of the world. In general, the closer a site sticks to the standards the better it will look across browsers and the more users you'll have access to. Your site will also be able to be much more clever incorporating things like animation and better interactivety with the user.

As always if you have any questions, comments or disagreements with what I've said here then drop me a line!

http://www.jamesburrows.info

CSS layouts vs Tables: What's the Pragmatic Choice?

There's a debate going on in the Web world about Lockergnome's backwards conversion from a modern CSS design to a 1997-era HTML tables design. The web design community is outraged by the decision, because it's basically a slap in the face to the Web Standards movement. Photo Matt compares table-based designs to McDonald's food and XHTML/CSS designs to healthy, fresh food. Paul Scrivens and Dave Shea both ask: what's the point in going backwards? Those that agree with Lockergnome's decision argue that tables-based designs are still the easiest and most pragmatic solution. Scoble sings the Content is King rap and Rogers Cadenhead says that "...aside from accessibility issues, no one should care how pure your markup is."

I have to agree with Photo Matt and the other designers on this - Web Standards are important and Lockergnome's decision is short-sighted. What's more I'll argue below that CSS designs are the pragmatic choice - if not in the short-term, then very definitely in the medium and long term.

The fact is HTML is a structural-based mark-up language and HTML tables are NOT designed for presentational purposes. Using tables for webpage layout is a hack, pure and simple. CSS on the other hand is specifically designed for presentation purposes. All modern browsers support CSS now, unlike browsers circa 1997, so there's little excuse not to separate structure (HTML/XHTML) and presentation (CSS).

(aside: stay tuned for my upcoming Digital Web article, which I recently submitted for review. It has a section on this very point).

But actually it's no use me moralising, I need to provide some pragmatic reasons why people should want to use XHTML/CSS...

I wrote an article back in October 2003 explaining why I'd decided to move my Radio Userland weblog from the default tables-based design to an XHTML-compliant, CSS layout. Let me briefly re-iterate some of my reasons:

- While in the short-term CSS is harder to implement than tables, in the medium-term CSS is easier to maintain. Having to fuss around with a bunch of table cells in order to re-jig a design layout, is more hassle than simply modifying a couple of lines in a CSS file.

- XHTML/CSS designs convey semantic information about the structure of your site. While you may not see many benefits of this today, think of these future benefits: Your site will be more easily rendered on mobile devices, it can be easily re-purposed to another format, it can be probed and analysed using XPath and other such technologies, it can be re-mixed and transformed with other XML content, and so on.

There are also more practical web design reasons too - e.g. CSS designs use up less bandwidth than table-based designs. All of these reasons make XHTML and CSS the pragmatic choice when viewed from a medium and long-term perspective.

RSS is actually a very good example of the value of semantically-structured web publishing (and publishing is what we do with websites too). RSS is an XML data format and the content is wrapped up in semantically-meaningful tags. I don't want to get into a debate about how semantic RSS 2.0 is compared to RSS 1.0 or Atom (that'd be like jumping out of the frypan and into the fire!). My point is that web publishing is no longer just about slapping together some HTML tags, placing it on the Web, and 'Bob's yer Uncle' that's the end of the process. When we publish to the Web using semantically rich structures and Web Standards, we make it a whole lot easier to share and re-use content. The process doesn't end when we publish - it's only just begun. That's sort of what I was getting at the other day with my There is no End User post. But I'm still working on that theory...

Written by Richard MacManus

CSS Layouts Vs. Table Layouts

CSS Layouts Vs. Table Layouts - Alternate Browsers and Accessibility Issues

When developing a web site one can choose between creating a CSS-based or TABLE-based web site. Both types of layouts have advantages and disadvantages and perform quite differently. They also raise (or address) accessibility issues.

This article will try to focus alternatively on each layout and point out the course of action for web developers employing either of them so as to improve the accessibility of their website.
TABLE-based layouts

Tables have been used in designing web sites for a very long time. Yet, even today, with the multitude of browsers available, many compatibility and accessibility issues rise to the surface. All these issues must be addressed in order to ensure a web site is completely functional to all users including those using alternate browsers.
Facts about web sites using tables

- They're easy to use and implement (compared to css-layouts).
- WYSIWYG (What You See Is What You Get) editors like Frontpage and Dreamweaver make it very easy for developers to include them.
- Tables "break" on various browsers (newer and older versions) thus producing layout dysfunctions.
- Increase almost unnecessarily the HTML/text ratio. This means that other options could be used to create layouts that produce smaller page files by employing less HTML tags.

We see tables being used on over 95% of the websites on the net today. We see them being used on web sites with heavy content like news sites as well as on simpler sites like corporate sites or educational sites.

Among the many issues related to tables, the most disturbing one (for users as well as web developers) is browser compatibility. Among the most common browsers today, we see Internet Explorer, Netscape, Opera and Mozilla. However, there are several versions of each on the market. This means that web sites should be tested on as many versions as possible in order to obtain an accurate compatibility analysis.

During the compatibility analysis we see that on other browsers than Internet Explorer the table layout "breaks". We see gaps that should not be there, or weird positioning of cells or even thicker rows or columns than intended. Such issues require a lot of extra effort and time on the developers' part to fix. Strangely enough, a table layout can even look broken on Netscape 6.x due to the DOCTYPE declaration at the beginning of the source file.

Admittedly, the developer can not always be accountable for layout dysfunctions. There are numerous bugs all browsers have that can cause that.

When using WYSIWYG for designing a web site the risk of "bloating" the source code with unnecessary tags (or invalid tags for that matter) rises significantly. The less experienced web designers are faced with having to fix what a software broke.

Text browsers, screen readers and speech output browsers read the source code line by line and then render it to the user. If cells aren't linearized, meaning that when reading Cell1, Cell2, Cell3 and Cell4 the content does not read in a logical flow, then the information becomes difficult to retrieve for disabled users. The above mentioned situation can occur when you have navigation in Cell1 and Cell3 and content in Cell2 and Cell4.

Alternative browsers will also have difficulties rendering content properly if the layout uses tables within tables or table cells. This would break up the logical structure of the page.

---------------------

CSS-based layouts

CSS or Cascading Style Sheets have been used until now for text formatting but recently, developers have started using it for positioning and layouts. CSS layouts are still difficult and time-consuming to implement but their advantages are certainly worth the trouble.

Facts about CSS layouts

- Widely supported by modern browsers but not by older browsers
- Allows extreme flexibility in positioning
- Increases usability by encouraging liquid design
- Keeps the HTMl/text ratio at a low level thus decreasing load time
- Allows the display of main content first while the graphics load afterwards

Although almost all modern browsers have good CSS support, older browsers are at a disadvantage. However, on older browsers a CSS-based layout still proves to be usable by displaying navigation and content at the beginning of the page.

By making use of its flexibility, developers can easily create layouts that expand as much as the screen allows it. Another advantage is that by changing a single .css file one can completely change the aspect of the site, making it perfectly suitable for screen or printing.

Because of increased positioning options, the main content can be placed at the top of the source code. This causes the information to display first and leave the bandwidth consuming elements to load at the end. This proves to be much more usable for users because they do not have to wait for an entire table with content and graphics to load as it happened with TABLE-based layouts. Users have now to wait much less before the relevant information is displayed..

Increasing accessibility through CSS

Graphic intense sites or those that employ elements that prove inaccessible to disabled users can put CSS to good work by placing all these elements at the bottom of the source code. This way, normal browsers will render the layout properly for normal users, letting them enjoy the visuals while alternate browsers will easily render the simplified, informational content to disabled users.

Using CSS can also avoid accessibility issues raised by table cells. When creating CSS-based web sites the content flows logically without disruption.

By Craig from TX.

http://www.ex-designz.net/articleread.asp?aid=323