Table Manners - HTML Tables

[DTP Articles]
[Vector Articles]
[Bitmap Articles]
[Web Articles]
[3D Articles]

[Free Photos]
[Colour Management]
[Photo Sharing]
[Drupal Tutorial]
[Introducing CMS]
[Photo to Art Tutorial]
[3D Rendering Tutorial]
[Future of Web Design]
[Google Bourbon]
[Google Background]
[Live Paint Live Trace]
[3D Materials]
[Extending Bitmaps]
[Image Modes]
[Elements 3]
[Flash Video]
[Flash Bitmaps]
[CD Authoring]
[Mac PC History]
[Best 3D App ]
[Photo Edit Roundup]
[Photoshop Patterns]
[Web Success]
[Texture Library]
[Web Stats ]
[Best Web App]
[Best Creative App]
[3D to 2D]
[Corel or Not?]
[Photo Bargains]
[2D to 3D]
[Creative Suite]
[CSS Positioning]
[Tablet PC]
[Pen Input]
[Acrobat Directions]
[HTML Tables]
[Filter Tips]
[Understand CSS]
[Photoshop Filters]
[Flash Usability]
[Web Fonts]
[2002 System]
[Font Formats]
[MX Explained]
[DTP Tagging]
[Image Resampling]
[Image Resolution]
[Data-Driven Design]
[Digital Video]
[Windows XP]
[Paper to PDF]
[Flash Animation]
[Page Imposition]
[Design Roundup]
[Graphic Roundup]
[eBook / ePaper]
[Image Management]
[Removable Storage]
[Understand Halftones]
[Web Buttons]
[XML Revolution]
[Bitmap Vectors]
[Image Enhancement]
[Windows 2000]
[PDF Workflows]
[Flash v LiveMotion]
[Advanced File Formats]
[Design Companies]
[Dynamic Filters]
[Site Structuring 2]
[Site Structuring 1]
[Image Hoses]
[Text Typography]
[Producing Panoramas]
[Spot Colour]
[SVG Format]
[Design Sites]
[Database Publishing]
[Vector Brushes]
[Layout Compositing]
[Brush Control]
[Web Repurposing]
[Digital Cameras]
[Automating Scripts]
[Stock Photography]
[Quark v Adobe]
[Bitmap Editability]
[1998 Applications]
[Photoshop 5 Colour]
[Asymmetric Grids]
[Bitmap Masking]
[Bug Hunting]
[Commercial Print]
[Vector Transparency]
[Scanning The Facts]
[Colour Print]
[Image Management]
[Preparing Print]
[Understanding EPS]
[DTP Grids]
[Layer Handling]
[NT or Not?]
[Hardware 1997]
[Microsoft Publishing]
[3rd Party Solutions?]
[Beyond CMYK]
[Acrobat v Immedia]
[Postscript 3]

[3D Rendering Tutorial]
[Acrobat Tutorial]
[Art Tutorial]
[Colour Management Tutorial]
[CorelDraw Tutorial]
[Drupal Tutorial]
[Flash 5 Tutorial]
[PageMaker Tutorial]
[Photo to Art Tutorial]
[Photoshop Elements 3 Tutorial]
[Photoshop Elements Tutorial]
[Photoshop Basics Tutorial]
[Photoshop Advanced Tutorial]
[Web Dreamweaver Tutorial]
[Web FrontPage Tutorial]
[Web Design / HTML Tutorial]
[Web Graphics Tutorial]

[Home / What's New]
[DTP / Publishing]
[Vector Drawing]
[Bitmap / Photo Editing]
[Web Design]
[3D Software]
[All Reviews]
[All Articles / Tutorials]
[Book Search / Shop]
[Site Map / Search]

you can help support the site with a direct donation or by shopping via the following links:


Thank you!



Understand the strengths and limitations of HTML table tags

Are HTML tables God's gift to web designers or the work of the devil? Tom Arah plots a middle way.

It's a hard life for web designers. Everything comes so easily to print-based designers with the ability to precisely set every feature of a page layout right down to the nearest thousandth of a point. This absolute certainty of a fixed page through precision PostScript is only a dream for web designers who must instead work to the vagaries of a near-infinite range of screen sizes through the browser-based interpretation of HTML. There's no need to despair though: it is possible to take control of your web page layout.

To begin with, it's important to recognize that HTML's fluid nature whereby the layout automatically flows to fill whatever size of browser window it is presented in, is actually very effective. In particular this "liquid" layout is ideal for the Web as first devised: a means of disseminating scientific papers. Having said this, such crude single-column layouts are hardly exciting, seriously limit what content can be shown at any time and, with full line lengths across high-resolution screens, can become virtually unreadable. Clearly we need to take greater design control to be able to treat the screen more like a page, but how?

The secret of layout on the Web is the HTML table.

The solution was pioneered by Netscape back in 1995 with the introduction of new tags for dividing the screen into tables. These were soon picked up by other browser developers and incorporated into the HTML 3.2 specification. Because HTML tables are tag-based it's possible to create them from scratch in a text editor but, by their nature, it's much easier to produce them in a visual authoring environment. Every HTML authoring package offers comprehensive control first accessed through an Insert > Table command where you specify the number of rows and columns that you want.

By switching to Code or Split view you can inspect the nested tags that are involved in producing a simple two-column by two-row table:

<table width="100%" border="1" cellspacing="0" cellpadding="0">

The all-embracing main element is the <table> tag itself which takes attributes that let you set the overall width - here set to 100% to fill the full width of the browser window; the border - here set to 1 so that we can see the table grid; and the cellspacing and cellpadding - used to control the spacing between cells and cell content.

Tables are created with a few HTML tags.

Interestingly there are no <table> tag attributes for the most fundamental factor of all: the number of columns and rows. Instead these are handled incrementally as they are downloaded, in keeping with HTML's page stream nature. First comes the opening <tr> tag to indicate the start of a Table Row, then any number of cells marked by the opening <td> and closing </td> Table Data tags (the "&nbsp;" code for a hard space is added to prevent browsers ignoring empty cells). When the browser hits the closing </tr> tag it can render the completed row and start on the next, lining up the new <td> data cells with those before to produce de facto columns.

It looks straightforward but it's worth experimenting by creating a multi-cell table and randomly scattering varying amounts of text through it. Within your authoring package each column will start off as equally spaced and each cell will grow vertically to accommodate its text as you'd expect. Preview the page as it will actually appear though and the results are very different: those columns with cells containing more content are wider than those containing cells with less! And if you resize the browser window the column widths will shrink and grow and the respective column widths change. And different browsers and versions might well produce different results!

The browser has its own ideas on table rendering.

It's bizarre behaviour that has reduced countless designers to nervous wrecks - so what is going on? Everything makes sense when you remember that the table tags were intended to handle scientific data. The browser's main function is to show all tabular data on whatever screen size it is presented with, and it has its own ideas on how that should best be done. According to Netscape "complex heuristics are applied to tables and their cells to attempt to present a pleasing looking table." The problem is that for the designer this "smart formatting" is often anything but clever and the results anything but pleasing. Clearly the designer needs to take tighter control of the sizing of their tables.

In fact this is relatively straightforward - at least in principle - as both <table> and <td> tags offer a "width" attribute. In fact we've already seen this in action with the "width="100%" <table> tag attribute which sets the table to fill the full browser window. Other percentages are possible and in the same way you can set each <td> cell to be a proportion of the total table width. Much more significant for the designer is the ability to set absolute sizes in pixels so that <td width="500"> will create a cell - and so column - 500 pixels wide irrespective of the size of the browser window. In fact the width isn't absolutely fixed as it is in a DTP application as a cell will still expand if its width setting is too small to contain its content (most commonly an embedded bitmap image), or if a later cell in the same column has a wider setting - but it's still a massive advance.

At last we've got the control we need to begin laying out our web page. The first decision is the most important - assuming we want a fixed-width layout what width should it be? We still have to face the fact that all screen sizes are different and the big danger is that if we set a table width that is larger than the browser window then the end user will have to scroll horizontally to read every line in turn! Clearly they won't do that for long and your reader will be lost. The obvious solution is to go for the lowest common denominator which, on the desktop, is 640 x 480. Then you have to factor in elements such as scrollbars and different browser set-ups, again working to the lowest common denominator (in this case Internet Explorer 4.5 on the Mac). Playing it very safe leads to a total width of around 580 pixels.

But of course the main advantage of using tables is that it enables side-by-side text. The classic web layout is to have a column of alternative page links down the left of the main body copy. This is easy enough to achieve with the Table > Insert Column command which automatically adds all necessary <td> elements to the existing <tr> elements (much simpler and safer than hand coding). By default the <td> cells have no width attribute but we can change this by interactively dragging on the cell side. Note though that in many applications the resulting widths don't add up to the full table width so it's better to set this manually. For the links column a width of 130 pixels leaves 450 pixels for the main copy column. It might not sound that much, but at the browser default text size it leads to readable line lengths of between 12 and 15 words.

So far so good but our 2-column 1-row layout is still very basic. We can quickly add more rows and columns with the Table > Insert commands and, crucially, we can merge adjoining cells with the Table > Merge Cells command. Take a look at the code and you can see how this is achieved via two new <td> element attributes, namely "colspan" where the cell straddles multiple columns and "rowspan" where it straddles rows. The obvious use for this is on a table of scientific data where you can create a first header row that spans the width of the entire table.

With spanning and nesting you can build more advanced layouts.

That's the obvious and original use of cell spanning but it's not the only use. There's nothing to stop us from merging cells anywhere in the table grid which opens up much greater design potential. We can also use the Table > Split Cell. command to further subdivide the table grid. Look at the code and you can see how this is achieved not through a new attribute, but rather by adding new blank <td> elements and applying the appropriate colspan and rowspan attributes to surrounding cells. Alternatively, if you want to split an existing cell into both rows and columns you can simply use the Insert > Table command. In fact there's nothing to stop you repeating the process to create multiple nested tables.

Let's see this new design power in action. Returning to our simple two-column layout we can add a new row with the Table > Insert Row command. We can then merge these two cells to create a single header cell that straddles the whole layout which is ideal for a typical web page banner. We can then insert another row above the page links and body copy row to contain links to the main site sections. Finally we can merge these cells and insert a new 1-row 6-column table into which we can enter the links.

Using these few commands we've created the basic banner/ section links/ page links/ body copy framework that you see on so many web sites. More to the point we've learned all the tools necessary to create far more advanced web page layouts. For our home page, for example, we could sub-divide the main body copy cell into a grid into which we can drop taster stories and links. Or we could increase the width of our layout by adding a new column down the right. That would mean targeting larger 800 x 600 displays but, if we make sure that no column is more than 580 pixels wide, then even users of smaller displays will only have to use the horizontal scroll bar once to set up their reading of the main copy. There's one final thing we need to do. By setting all <table> elements' border attributes to zero we can hide the table grids on which each page is built.

This is impressive stuff: so long as the layout is based on non-overlapping rectangular components we can build it. More to the point we've managed to gain pixel-level control of our design, at least horizontally. In fact we can take similar control vertically thanks to the <td> element's "height" attribute - though again with the proviso that the cell will always expand to contain its content. This is virtually DTP-style control so the obvious question is: why can't we have a DTP-style implementation?

In fact this is exactly what wysiwyg authoring packages like NetObjects Fusion have always offered. The user drags text and picture blocks onto the page and, behind the scenes, Fusion takes care of producing the correctly-sized table tags needed to reproduce the layout in the browser. Rather more advanced is the system pioneered by Adobe GoLive and then picked up by Dreamweaver with its Table Layout View. Here you drag out a Layout Table container and then, within this area, drag on and size and position Layout Cells into which you plan to drop content. As you do so, you can see the outlines of the complex colspanned and rowspanned table grid that will actually produce the final desired results.

In Table Layout view you can add Layout Cells anywhere onscreen.

We've certainly come a long way from those original browser-interpreted columns of scientific data. By creatively commandeering HTML tables we've gained almost DTP-style control over our layouts. Tables are the secret behind virtually every web page out there but, before we get too pleased with ourselves, it's time to take a reality check and to look at the code. It's not a pretty sight. Take a look at the HTML for a typical grid layout produced in Table Layout view, for example, and you'll see reams and reams of table tag code with vast numbers of empty <td> cells outnumbering the few oases of content.

It's not exactly how Tim Berners-Lee imagined the semantic Web, but so what if the code is complex - if it does the job does it matter? Well yes for one over-riding reason - efficiency. To begin with, complex table code affects efficiency in terms of editability. The more advanced the table layout the more difficult it is to edit. Each <td> table cell is not actually a self-contained DTP-style text and picture box so each time you want to move or resize one there are repercussions on the layout as a whole. Even minor adjustments can be a nightmare and you can forget about easy repurposing.

The complexity of HTML table grids is even worse news when it comes to rendering. We've already seen that, unless pinned down, different browsers will interpret the same tags differently. With more complexity there's more room for disagreement, such as how to handle mixed pixel and percentage attributes or column widths that don't add up to the table width, and so more danger that the layout will break. On top of which remember that even the best table layout is never absolutely fixed. All it takes is for the end user to change their default text size so that a cell has to expand to contain its content and your carefully constructed table can fall apart like a pack of cards. Things are certainly better than they were, but it's still necessary to check your table layouts against the most common viewing set-ups to ensure there aren't any nasty surprises lurking.

The problem with tables is even more fundamental than this. Browsers were designed to efficiently display tagged text but these days, because of tables, many web pages contain more tags than text! In other words the browser's primary task has come to be rendering the table rather than its content. That's bad enough, but the way that HTML tables have been designed to be rendered incrementally row-by-row as the code downloads proves fundamentally flawed in a high-design context. While the system works as intended for regular, fixed-column tabular data, for an advanced layout grid the browser might well find that later information in the form of a new column width (either specified or content-dictated) or even an entirely new column, will retrospectively affect everything that's gone before! With Netscape you often see this as disconcerting re-juggling onscreen while with Explorer the table rendering is usually delayed until every <td> in every last nested <table> has been parsed.

.but make the table border visible and look at the code and you can see the downside of such handling.

Suddenly HTML tables appear in a new and much less attractive light. Rather than the design saviour of the Web, HTML tags now seem like an unwelcome parasite overwhelming its host with reams of inefficient and unreliable code that break the whole principle of HTML's streamlined, flexible and fast-rendering layout. Surely there has to be a better way?

There is and it comes in the form of Absolute Positioning which shifts web page layout control from HTML to the dedicated CSS2 (Cascading Style Sheets Level 2) in much the same way as text formatting is best handled by CSS1. Absolute positioning is definitely the future (and a future article), but until browser support develops and critical mass is reached, HTML tables are going to remain the layout mechanism of choice for the vast majority of web pages. So the obvious question becomes: what can you do to optimize their use?

The secret is to see your tables from the browser application's point of view. To render the table as efficiently and reliably as possible, the browser needs to know as much information as necessary as soon as it can. That means specifying all attributes such as cellpadding and cellspacing so that there's no scope for varying interpretation. You also need to specify column widths once-and-for-all and as soon as possible, preferably in the first row, and to make sure that you don't mix percentages and pixels and that your figures add up. And you need to make sure that the content you intend to put in your cells will fit. You can also help your browser by adding HTML 4's <col> and <colgroup> elements to specify the number of columns and their width up-front - though authoring and rendering support is patchy. Also if you've set up your table and column widths correctly you can use the CSS2 {table-layout: fixed} property to switch supporting browsers to faster incremental rendering.

Adding information in this way helps the browser render your table, but much the best approach is to keep it simple. Most importantly you should avoid the code bloat involved in mimicking wysiwyg DTP-style content box layouts, but the principle goes further. By their nature features such as "rowspans" and nested tables delay rendering. The more you can break up your tables into simple incremental units the better. With our traditional banner/site links/page links/body copy layout for example, we could actually treat each cell as a separate table (we'd need to left-align the page links table so that the two tables appear side-by-side). This means that each page element can render independently as it is downloaded rather than being tied to the others. The actual rendering time for the page as a whole will be roughly the same but psychologically the fact that some content appears quickly can easily make the difference between a text-heavy page that is read and one that isn't.

HTML-based tables have a huge amount to offer the designer (try imagining the Web without them), but it is important to recognize that they are a double-edged sword. Ultimately the most important tool when it comes to designing your web pages' layout isn't your powerful but profligate web authoring package - it's a pencil and paper with which you can hone down your design to its bare but elegant essentials.

Tom Arah

June 2003

Hopefully you've found the information you were looking for. For further information please click here.

For free trials and special offers please click the following recommended links:

For further information on the following design applications and subjects please click on the links below:

[3D], [3ds max], [Adobe], [Acrobat], [Cinema 4D], [Corel], [CorelDRAW], [Creative Suite], [Digital Image], [Dreamweaver], [Director], [Fireworks], [Flash], [FreeHand], [FrameMaker], [FrontPage], [GoLive], [Graphic Design], [HTML/CSS], [Illustrator], [InDesign], [Macromedia], [Macromedia Studio], [Microsoft], [NetObjects Fusion], [PageMaker], [Paint Shop Pro], [Painter], [Photo Editing], [PhotoImpact], [Photoshop], [Photoshop Elements], [Publisher], [QuarkXPress], [Web Design]

To continue your search on the site and beyond please use the Google and Amazon search boxes below:

Web independent, informed, intelligent, incisive, in-depth...

All the work on the site (over 250 reviews, over 100 articles and tutorials) has been written by me, Tom Arah It's also me who maintains the site, answers your emails etc. The site is very popular and from your feedback I know it's a useful resource - but it takes a lot to keep it up.

You can help keep the site running, independent and free by Bookmarking the site (if you don't you might never find it again), telling others about it and by coming back (new content is added every month). Even better you can make a donation eg $5 the typical cost of just one issue of a print magazine or buy anything via or (now or next time you feel like shopping) using these links or the shop - it's a great way of quickly finding the best buys, it costs you nothing and I gain a small but much-appreciated commission.

Thanks very much, Tom Arah

[DTP/Publishing] [Vector Drawing] [Bitmap/Photo] [Web] [3D]
[Reviews/Archive] [Shop]  [Home/What's New]

Copyright 1995-2005, Tom Arah, Please get in contact to let me know what you think about a particular piece or the site in general.