COM271, Week 1

<Table>: Two Things to Remember

Syllabus | Table of Pages | Assignments | References and Useful Links

Tables Are for Tables, Not for Layout!

Keep in mind html's humble origins as a vehicle for sending simple text documents over the primitive web, including text organized in tables.

We put data in tables because scientists have taught us that this method of presentation has a logical meaning, one that is so familiar to us that we don't think about it. That is,

• Columns of a table differ from each other in kind, but within each column all of the data shares a set of common traits. We might have a column of text with a heading "Name," and of course that is all that we expect under the heading (names, not addresses or telephone numbers).
• Similarly, rows differ from each other, but within each row, the information belongs to a single set, usually identified by something in the first column. In the row where the first column says "Joe," we expect the columns that give us an address and telephone number are giving us Joe's address and telephone number, and no other.

That is, there is an underlying logic to the structure data in tables.

Tables, of course—particularly when we take advantages of their attributes for height and width—provide a convenient way to keep things lined up. Developers got into a habit, in their early days, of structuring their page layout by putting things in tables. In a simple 2 x 2 table, a logo went nicely in the upper left, an informative banner in the upper right. In the lower left cell, navigation took up residence, and the lower right left us space for the main content of the page. Users still look to these places to find answers to important (albeit unstated) information: (From top to bottom and left to right) Am I still on the same site (logo)? Where am I (banner)? Where can I go (navigation)? What's here (content)?

Want a third column on the right for news items, or a third row at the bottom for footer information? No problem, just add to your table.

Clever developers soon understood that by assigning (using width attributes) a fixed width to the navigation cell (and another fixed width to the "news items" cell), but making the table width a percentage (width="80%"), a page could be made flexible ("stretchy"), getting wider or narrower depending on the size of the window that contained it. Page layout was easily achieved just by placing things inside of table data elements. And if you set the table's border attribute to zero (border="0"), no one would even know you were doing all this clever layout with a table! You are so smart, developer!

But not so fast....

We will use an html table to achieve layout in our first assignment. Billions of web pages do this, and there will be times—mainly when you are doing something very simple and with very little time to do it right—when using a table for page layout (or for layout on a part of the page) makes perfect sense. On these occasions, go for it (and don't let any thought of Dr. Logan leave you with a guilt trip).

But after dwelling ever so briefly in the land of old-fashioned web pages with html only, we'll leave behind the distant (1995) past and get to the way things are done today. For the most part, we will adopt the W3C's philosophy of HTML for structure and CSS for layout, and we will clean up our markup by reducing the html and accomplishing the same layout goals (infinitely more efficiently) by using CSS. This will include positioning parts of the page, which we will learn to do in our third assignment. After that, we will never look back to use tables for layout (except when we are rushed and think we can deal with the guilt).

One Final Admonition Against Tables for Layout

Most of our pages this semester will be small, seldom long enough to require scrolling down once or twice to see everything. This is typical of most web pages. But you will soon envision pages full of lengthy texts, lots of your gorgeous photographs of your dog and sunsets, and pages of your glorious blog postings. Do you want to keep all of these tidy by using tables for layout? Probably not.

Browsers will not (because they cannot) begin to render parts of a page until they know how much space they will take up. If you have a paragraph of text, the browser will download it until it encounters the end of paragraph marker: now it knows how much text there is and it can start to display it on the page immediately. If you put an image on your page, the browser will begin displaying as the image comes down.

But what if the image, or all of your text, is inside a table data element? When does the browser know how wide or long the element will be? It's can't begin to display until it can draw the borders of the cell (how wide? how high?), and it won't. So it won't be able to display the row or the table that contains the text or image. And what if that table is itself contained inside another table (the one you are using for layout, despite the above)? The layout table won't be displayed either. Now what if the entire page is actually contained inside tables like this? Screen after screen of text and images will be streaming into your browser, but the user will not see anything rendered until the browser has exactly enough information to size up the outer table. Users may be long gone before that happens.

It gets worse. With a browser display on a screen, you can scroll down. But when you want to transfer the contents of a page to print media (you did want to print that image and the text so you can read it in bed tonight, didn't you?), everything has to be chunked into pieces no larger than 8.5 x 11 inches. Believe it or not, some browsers can't do that if you've put everything in a table. You'll get a single sheet with text dribbling off the bottom of the page and the rest of the tabled information will never show up!

There are solutions to these problems. First, don't fall into the habit of using a master table to achieve page layout. Second, break up tables. Even if (because I know you aren't going to listen to me) you want to use tables for layout, at least break up the tables. Use one for banner and logo, and then end it. When your browser can, it will render the top of the page, and the user will experience that magical "something is happening" that is essential to sticking around to see what's next. Break larger tables into smaller ones; instead of placing rows of information in a single table, make each row a table itself!

You might think that you would always know the content of a page, and with static web pages you would be correct. But often, you will be deriving content from a database, and you never know whether you are going to get a handful of lines and images, or screens and screens in response to a user request. Certainly, good page design will shun placing the entire thing inside a table that is intended for layout only.

Okay. Done preaching. Let's get that first assignment behind us.