HTML Utopia: Designing Without Tables Using CSS. Chapter 1: Getting the Lay of the Land | 3 | WebReference

HTML Utopia: Designing Without Tables Using CSS. Chapter 1: Getting the Lay of the Land | 3

HTML Utopia
SitePoint Books
By Dan Shafer
ISBN: 0-9579218-2-9

Chapter 1: Designing Without Tables Using CSS

We can look at Cascading Style Sheets (CSS) from a number of contextual perspectives. I prefer to view them as a correction to a fundamental mistake that was made at the beginning of Web Time, back in the old days of the early 1990s, when Tim Berners-Lee and the first pioneering Web builders first envisioned the beginnings of the Web.

What was that mistake?

To meet the requirements of the Web’s initially limited purpose, it was not necessary to separate content from presentation. Even though some thought it was a good idea, there was no really compelling, practical reason to recognize this distinction. After all, the Web’s early intent was simply to allow a small number of nuclear physicists using disparate systems at various locations to share vital experimental data.

Berners-Lee didn’t envision the massively popular, wildly commercialized, extensively morphed Web that emerged from his core ideas in the early 1990s—I doubt that anyone could have.

So, the mistake was a lack of foresight, rather than an oversight. But it was a mistake nonetheless.

Almost as soon as the Web became popularized by the emergence of the first graphical Web browser (the forerunner to Netscape Navigator), graphic designers became aware of a problem. The method by which the Web browser displayed information stored in HTML files was not within the designer’s control. No, it was the users who were in primary charge of how the Web pages they visited would appear on their systems.

While there were many, including myself, who thought this was A Good Thing, professional designers were beside themselves with concern. From their perspective, this constituted a fundamental flaw. "Users don't know anything about good design", they argued. If the designers couldn't control with great accuracy things like colors, fonts, and the precise, pixel-level positioning of every design element on the Web page, their creations could easily end up as ugly travesties in the user’s browser.

While a few decided to look upon this as a challenge posed by the new medium, most designers, accustomed to print and other fixed layouts that afforded them complete control over what the user saw, found ways to bend the Web to their will.

Lest I incur the ire of every designer reading this book, let me hasten to add that I don’t think this was A Bad Thing. It is certainly the case that designers know more about how content should be displayed for users than do the users themselves. Things like spacing, color combinations, and other design elements affect readability and usability. My point has much less to do with who should have been in charge, than it does with the actions to which designers were more or less forced to resort, in order to achieve at least some measure of control.

Soon, expert designers discovered that they could use tables to gain significant control over the presentation of content to users. By carefully laying out tables within tables within tables, they could position quite precisely any design element that could be contained within a table cell. And that encompassed almost everything.

The first desktop publishing-style Web page design tool, NetObjects Fusion, enabled designers to lay out pages with a high degree of precision. It generated complex, table-based HTML, which resulted in Web pages that were as close as possible to the designer’s original vision.

We never looked back.

But tables weren’t intended to be used as layout tools, so while they were marginally effective, they were also horribly inefficient. We’ll explore some of the shortcomings and disadvantages of using tables for layout tasks a little later in this chapter; for now, just know that everyone, including the designers who used the techniques, understood pretty well how clumsy a solution they really were.

CSS emerged as a standard for Web page design, in large part, as a reaction to the overuse of excessively complex tables to force precision layout upon a medium that was not originally intended for such a purpose. While this is a bit of an oversimplification of the facts, it’s hardly an unfair one.

After a brief series of skirmishes at the beginning of the Web’s development, the question of who should control the overall appearance of a page or site ended with the designers as victors. In fact, hardly a shot was fired. Users, after all, eventually care most about usability, accessibility and convenience, rather than the nitty-gritty details of design techniques.

Though flush with their victory, designers found themselves hard-pressed to identify very good, standards-compliant ways to provide their customers—and their customers’ users—with great designs that were also effective and efficient. Thus, they were forced to rely largely on tables.

As the snarl of tables grew to resemble a giant thicket, even the design community became uneasy. Maintaining a Web page that consists of a half-dozen or more deeply intertwined tables is a nightmare. Most designers prefer not to deal with code—even simple HTML markup—at such a level of detail.

Into the breech stepped the World Wide Web Consortium, better known as the W3C, a body founded by Tim Berners-Lee to oversee the technical growth of the Web. They saw that separating the content of a site from its form (or appearance) would be the most logical solution. This 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 the site’s aesthetics independently of its content.

The result was CSS.

Created: March 27, 2003
Revised: June 10, 2003