HTML Utopia: Designing Without Tables Using CSS, Chapter 1: Getting The Lay Of The Land

CSS In Context

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.

The Basic Purpose of CSS

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.

Why Most – But Not All – Tables Are Bad

Why are tables such a bad idea as a design mechanism? There are numerous reasons, but the ones we’re most concerned with in this context are:

• They result in load times that are longer than necessary.
• They encourage the use of inefficient “placeholder graphics” that further slow performance.
• Their maintenance can be a nightmare in which even minor changes “break” the entire layout.

Tables Mean Long Load Times

Most people don’t know that Web browsers are deliberately designed to ensure that each table downloads as a single entity. So, none of the material that’s contained in a table will be displayed until all the contents of that table are downloaded to the client machine, and available for display.

When the original, intended purpose of tables is taken into account, this makes sense. Tables were designed to display… well… tables of data. Each cell contained a value that was being compared to, or related with, the values of other cells in the table. Isolated bits of data appearing quasi-randomly would not do; the table was a single, integrated entity.

When designers began to rely on tables to contain all or most of the content of a Web page, they were also saddled with the consequences of this design decision. In addition to the apparent delay that many users experience as a result of tables displaying all at once, the sheer volume of HTML code that is required to create today’s Web page layouts with nested tables can also add actual load time due to increased page size. Table-based layouts almost certainly account for more user concern over long page load times than any other single factor.

Avoiding this significant load time would obviously be A Good Thing.

Use of Transparent Images Slows Us Down

Even with the availability of tables as layout mechanisms, designers could not quite attain the detailed level of control over page design that they wanted.

Sometimes, for instance, a designer might need a bit more breathing room around one part of a table cell (something for which table design does not allow). This kind of precision was unachievable.

Early on, some designer came up with the notion of creating a transparent.gif image file – a tiny GIF image that had no visible content. By creating table cells to contain these transparent images, we could force extra room both vertically and horizontally into tables whose cells were designed to remain in close proximity to one another.

The problem is, given a table with dozens or even hundreds) of these images, and depending on a variety of other factors, the performance impact of transparent GIFs on a Web page can be significant. More importantly, however, this technique will often restrict the page to a fixed pixel size, and it clutters the page with images that have no actual meaning for the content of the page. As we’ll see later, this severely impacts the ability for users with disabilities to make sense of your site.

Maintaining Tables is a Nightmare

The third reason why most tables are bad is that maintaining a complex array of deeply nested tables is a nightmare. If you use tools such as Macromedia Dreamweaver or Adobe GoLive to manage your sites and their designs, you can generally ignore the messiness of the nested tables that make the design possible.

But even these tools are not foolproof, and when they “mess up” (to use a highly technical term), amending the unsightly pages they create can be quite a challenge.

If you’re like most designers, and you wouldn’t be caught dead using an HTML-generating tool because you feel you gain more control and understanding if you hand-code everything, then you’ll be familiar with this problem.

The difficulty arises because, by necessity, tables have a fairly complex set of tags, even if they aren’t embedded within other tables. And when we have nested tables, well, we’ve got a clear case of the uglies alright.

The situation is further complicated by the fact that, unlike programming editors, HTML editors generally do not force or support the clean indentation of code.

So, finding the start and end points for a given table, row, or even cell turns out to be what software folks call a “non-trivial task.” While it’s true that a competent HTML coder or designer could make this problem more tractable, it’s never really solvable, no matter what we do.

When it’s OK to Use a Table

There is one notable exception to the cardinal rule that Tables are A Bad Thing. If you have tabular data, and the appearance of that data is less important than its appropriate display in connection
with other portions of the same data set, then a table is in order.

In general (though there are undoubtedly some exceptions to this rule as well), this means that the use of tables should be confined to the presentation of numeric or textual data, not graphics, multimedia data types, forms, or any other interactive user interface components.

What is CSS, Really?

OK, now that we’ve established that an important role of CSS in our lives as designers is to free us from the drudgery and treachery) of using tables for page layout, let’s take a look at what CSS really is.

The most important word in the Cascading Style Sheets label is the middle one: style. The cascading issue becomes important only when we get into fairly complex style usage, while the word “sheet” is even a tad misleading at times. So, even though we mean Cascading Style Sheets in the broadest and most accurate sense, we’ll focus not on the cascading or sheet-like nature of these beasts, but on their role in determining the styles of our Web pages and sites. Styles are defined in the form of rules.

These rules tell any Web browser that understands them (i.e. that supports CSS) how to display specific types of content structures when it encounters these structures in delivering a Web page to a
user.

To understand how styles affect Web page appearance, we need to be sure we understand what happens to a Web page in the absence of any style rules.

Figure 1.1 shows the general process of interaction between a client (Web browser), and a server where a Web page or site is located. Note that the browser automatically determines how information provided by the server is displayed to the user, unless it is specifically told otherwise. In other words, each browser has a default way of displaying all HTML-tagged content. So, a first-level heading enclosed in the <h1></h1> tag set will always be displayed using a relatively large font in black. The “default” font that’s used may vary between browsers, and can be affected by user-defined settings as well.

Figure 1.1 Normal Browser Page Display Behavior

Figure 1.2 depicts what happens when a style rule exists for a particular type of HTML structure. The rule overrides the browser’s default handling of that element, and the style takes over. Even if the user has defined his or her own settings for this element, those wishes will generally not be honored (though there are some intriguing exceptions to this, which we’ll discuss much later in this book).

Figure 1.2. Browser Displaying Page With Style Rule in Effect

Parts of a CSS Rule

Every style, whether it’s embedded in a separate style sheet or not, consists of one or more rules. Figure 1.3 shows a CSS rule with all the parts labeled.

Each rule has exactly two parts:

1. a selector that defines the HTML element(s) to which the rule applies, and
   
2. a collection of one or more properties, which describes the appearance of all elements in the document that match the selector.

Figure 1.3. Parts of a CSS Rule

Each property consists of a pair of values separated by a colon. The first item of the pair defines the specific property that’s being modified. The second item describes the value that the property takes on. Each property-value pair must be followed by a semicolon, with one exception: The semicolon following the last property is optional and may be omitted. In this book, however, we will always add this optional semicolon. I encourage you to adopt this habit as well, as it’s much easier to train yourself to always add that semicolon than it is to remember when it is required and when it isn’t. It also makes it easier to add properties to an existing style rule.

Here are a few examples of increasingly complex CSS rules, with the parts identified so that you can fix this syntax clearly in your mind. Essentially, this is the only real syntax issue you must learn in order to master CSS, so it’s important!

h1 {    

color: red;    

}

The selector, h1, indicates that this rule applies to all h1 headings in the document. The name of the property that’s being modified is color, which applies to the font color. The value we want the color property to take on is red. Chapter 7 and Chapter 9 explore fonts and coloring in CSS in great detail.

p {    

font-size: 14px;    

color: green;    

}

The selector, p, indicates the style rule should be applied to all paragraphs in the document. There are two property name-value pairs in the rule. The first, fontsize, sets the size of the font in all paragraphs in the document to 14 pixels. A pixel is one dot on your screen, and is the most common measurement used in CSS. See Chapter 3, for an explanation of this and other measurement issues in CSS. The second property is color and is set to green. The result of this rule is that all paragraphs in the document will appear in a green, 14-pixel-high font.

p {    

font-family: 'New York', Times, serif;    

}

Again, this rule deals with paragraphs, as is evidenced by the p selector. This time, the selector affects the font family that is used to display text. The new wrinkles in this example are that it includes a list of values for the font-family property, and one of those values is enclosed in quotation marks.

The font-family property is one of a handful of CSS properties to which you can assign a list of possible values, rather than a single, fixed value. When you use a list, commas must separate its individual members. In this case, the fontfamily property list tells the browser to use New York as the font if the user’s machine has it installed. If not, it directs the browser to use Times. And if neither of these fonts is available on the user’s system, then the browser is told to default to the font used for serif type. Again, this subject is covered in more depth in Chapter 7 and Chapter 9.

Whenever the name of a property value in a CSS rule includes spaces (as is the case with the font named “New York”), you must put that value into quotation marks. Many designers use single quotation marks for a number of reasons, not the least of which is that they’re easier to type, but you can use either single or double quotation marks.

Types of CSS Rules

There are several possible ways to categorize and think about CSS rules. First, there is the question of what types of style properties the rules define. Second, there is the requirement of describing the type(s) of HTML elements that the rules affect. Finally, there is the issue of whether the styles are “inline”, “embedded” or “external.”

Let’s take a brief look at each of these categorizations, so that you have a good overview of the organization of CSS rules before you embark on a detailed study of their actual use.

What Properties Can CSS Rules Affect?

CSS rules can include properties that affect virtually every aspect of the presentation of information on a Website. A complete reference to these properties is presented in Appendix C.

What Elements Can CSS Affect?

Stated another way, this question asks “How specifically can a CSS rule target a piece of information on a Web page for special presentation?” CSS allows the designer to affect all paragraphs, but how can you confine that impact to certain, specific paragraphs? Is this even possible?

The answer, unsurprisingly, is yes. Through various combinations of selector usage, the designer can become quite specific indeed about the circumstances under which a style rule is enforced. For example, you can assign rules so that they affect:

• all elements of a specific type
• all elements of a specific type that are assigned to a common group or class
• all elements of a specific type that are contained within other elements of a specific type
• all elements of a specific type that are both contained within another specific element type and assigned to a common group or class
• all elements of a specific type only when they come immediately after an element of some other type
• only a specific element of a specific type which is assigned a unique ID

Chapter 3 includes a detailed discussion of all the CSS selectors you can use to achieve this kind of precision targeting.

Where Can CSS Styles Be Defined?

Finally, you can define CSS styles in any of three places, in conjunction with a Web page.

Inline CSS

First, you can define a style entirely within an appropriate HTML tag. This type of style is referred to as an inline style because it is defined in line with the document’s HTML code. You can assign a style attribute to almost all HTML elements. For example, to make a second-level heading in a document appear in red text and all capital letters, you could code a line like this:

<h2 style="color: red; text-transform: uppercase;">An Unusual     

Heading</h2>

If you follow the advice in this book, you won’t use many inline styles. As you’ll learn, separating content from presentation is one of the big advantages of CSS, and embedding styles directly in HTML tags defeats that purpose. Inline styles are mainly useful for rapid prototyping – quickly applying style properties to a particular element to experiment with an effect before giving the properties a more permanent place in an embedded or external style rule.

Embedded CSS

Specifying style properties in an embedded style is probably the method that’s most common today, particularly among beginning Web designers or those just learning the techniques involved in CSS design. It’s not my favorite, but it does have the singular virtue of being easy to deal with, so you’ll see it used from time to time in this book.

To embed a style sheet in a Web page, you place a style block in the head of the document’s HTML, as shown here in bold:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"     

"https://www.w3.org/TR/xhtml11/DTD/xhtml1-transitional.dtd">     

<html xmlns="https://www.w3.org/1999/xhtml">     

<head>     

<title>CSS Style Sheet Demo</title>     

<meta http-equiv="Content-Type"     

content="text/html; charset=iso-8859-1" />     

<style type="text/css">     

<!--     

h1, h2 {     

color: green;     

}     

h3 {     

color: blue;     

}     

-->     

</style>     

</head>     

...

The CSS rules contained in the style block apply to all the designated parts of the current document. In this case, the first rule directs the browser to display all level 1 and 2 headings (h1, h2) in green. The second rule displays all level 3 headings (h3) in blue.

Notice the HTML comment delimiters (<!-- -->) just inside the <style> tags.

These prevent ancient browsers that do not support CSS from interpreting the style rules as document content and displaying them in the browser window. All CSS capable browsers will ignore the comment delimiters. Even though it’s probably safe (or nearly so) to omit these symbols today, as so few ancient browsers are still in use, it does no harm to include them. I recommend you do so, just because it’s good form.

The second thing to notice about the style element’s syntax is that each rule starts on a new line, and each property specified within the rule appears indented within braces on its own line. This is not, strictly speaking, required, but it’s a good rule of thumb that improves the readability of your code, especially if you’re used to the look of JavaScript code.

External CSS

Finally, you can define CSS rules in a file that’s completely separate from the Web page. You can then link to this file by including a <link> tag in the head portion of any Web page on which you want to implement the styles contained in that file.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"     

"https://www.w3.org/TR/xhtml11/DTD/xhtml1-transitional.dtd">     

<html xmlns="https://www.w3.org/1999/xhtml">     

<head>     

<title>CSS Style Sheet Demo</title>     

<meta http-equiv="Content-Type"     

content="text/html; charset=iso-8859-1" />     

<link rel="stylesheet" type="text/css" href="corpstyle.css" />     

</head>     

...

In this example, the file corpstyle.css contains a set of external styles that
have been linked to this page. Here’s what the contents of this file might look
like:

h1, h2 {     

  color: green;     

}     

h3 {     

  color: blue;     

}

This is my personal preference for the way we should deal with all CSS usage, for a number of reasons.

First, this is the least “locked-in” of the three basic methods designers can use to insert styles into a Web page. If you define an external style sheet file, you can bring it to bear on as many pages on your site as you want, simply by linking to the style sheet from each page on which you want it used. Making a change to a style that appears on every page of your site becomes a simple matter of modifying the shared .css file. If you use embedded or, worse yet, inline styles, you’ll have to copy and paste them into other documents if you want to use them.

Second, and closely related to the first advantage, is that this method is the easiest way to ensure the maintainability of your CSS styles. If you define all your site’s styles in external files, implementing a site-wide style change is a simple matter of making one edit in a single file. All the pages that use that style sheet will display the new styles immediately, following this one change.

With the other techniques, you have to either remember which styles are defined on which pages, or use search mechanisms to help you deal with the decentralized styling rules.

Third, external style sheets are treated as separate files by the browser. When the browser navigates to a new page, using the same style sheet, the external style sheet does not need to be downloaded again. Pages that use external styles are therefore quicker to load.

Last, but not least, external style sheets are simply more professional. By using them, you demonstrate an understanding of the importance of the first two issues I’ve just raised, and you make it much easier to discuss them, share them with colleagues, analyze their effects, and, in general, to work with them as if they were a serious part of the site’s design, rather than an afterthought.

Why Bother?

Well, now that you have a basic overview of what CSS is all about, why we have it, and why I think it’s an important technique for Web designers to adopt, where’s the proof? Let’s look at an example of a small, but not overly simplistic Web page (see Figure 1.4).

Figure 1.4. Sample Web Page Demonstrating Embedded Styles

Using embedded CSS, here’s the HTML that will produce that page. Look ma, no tables! Don’t let the complexity of the code intimidate you – by the end of Chapter 3, you should be able to infer the meaning of most of it without my help. For now, you can download the code archive from the book’s Website and marvel at the results in your browser. The file is called ch1sample.html.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"      

"https://www.w3.org/TR/xhtml11/DTD/xhtml1-transitional.dtd">      

<html xmlns="https://www.w3.org/1999/xhtml">      

<head>      

<title>Basic 3-Column Sample Page</title>      

<meta http-equiv="Content-Type"      

content="text/html; charset=iso-8859-1" />      

<style type="text/css">      

<!--      

body {      

  background-color: teal;      

  margin: 20px;      

  padding: 0;      

  font-size: 1.1em;      

  font-family: verdana, arial, helvetica, sans-serif;      

}      

h1 {      

  font-family: verdana, arial, helvetica, sans-serif;      

  margin: 0 0 15px 0;      

  padding: 0;      

  color: #888;      

}      

h2 {      

  font-family: verdana, arial, helvetica, sans-serif;      

  margin: 0 0 5px 0;      

  padding: 0;      

  font-size: 1.1em;      

}      

p {      

  font-family: verdana, arial, helvetica, sans-serif;      

  line-height: 1.1em;      

  margin: 0 0 16px 0;      

  padding: 0;      

}      

.content>p {      

  margin: 0;      

}      

.content>p+p {      

  text-indent: 30px;      

}      

a {      

  color: teal;      

  font-family: verdana, arial, helvetica, sans-serif;      

  font-weight: 600;      

  text-decoration: none;      

}      

a:link {      

  color: teal;      

}      

a:visited {      

  color: teal;      

}      

a:hover {      

  background-color: #bbb;      

}      

/* All the content boxes belong to the content class. */      

.content {      

  position: relative;      

  width: auto;      

  min-width: 120px;      

  margin: 0 210px 20px 170px;      

  border: 1px solid black;      

  background-color: white;      

  padding: 10px;      

  z-index: 3;      

}      

#navleft {      

  position: absolute;      

  width: 128px;      

  top: 20px;      

  left: 20px;      

  font-size: 0.9em;      

  border: 1px dashed black;      

  background-color: white;      

  padding: 10px;      

  z-index: 2;      

}      

#navright {      

  position: absolute;      

  width: 168px;      

  top: 20px;      

  right: 20px;      

  border: 1px dashed black;      

  background-color: #eee;      

  padding: 10px;      

  z-index: 1;      

}      

-->      

</style>      

</head>      

<body>      

<div class="content">      

  <h1>Getting the Lay of the Land</h1>      

  <p>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 mid-1990's      

     when Tim Berners-Lee and a subsequent phalanx of Web builders      

     first envisioned the beginnings of the Web.</p>      

  <p>What was that mistake?</p>      

</div>      

      

<div class="content">      

  <h2>CSS in Context</h2>      

  <p>Almost as soon as the Web became popular, graphic designers      

     began noticing what they saw as a fundamental flaw: the      

     method by which a Web browser displayed information in HTML      

     files was not within the designers' control. No, it was the      

     users who were in primary charge of how the Web pages they      

     visited would appear on their systems.</p>      

</div>      

<div class="content">      

  <h2>Keep Adding Content</h2>      

  <p>You can see that as you keep adding content to this page, it      

     adds nicely boxed and centered material down the center of      

     the page.</p>      

</div>      

      

<div id="navleft">      

  <h2>Some Links</h2>      

  <p>      

    <a href="http://www.danshafer.com/"      

title="Dan Shafer's Personal Web Site">Dan's Home Page</a><br/>      

    <a href="https://www.sitepoint.com/"      

title="SitePoint Home Base">SitePoint Home</a><br/>      

    <a href="http://www.sitepointforums.com/"      

title="Discussion Board for This Book">Discuss This Book</a><br/>      

    <a href="" title="">Fake Link One</a><br/>      

    <a href="" title="">Nothing Here</a><br/>      

    <a href="" title="">Links Nowhere</a><br/>      

    <a href="" title="">Fake Link Four</a><br/>      

    <a href="" title="">Fifth Fake Link</a><br/>      

  </p>      

</div>      

      

<div id="navright">      

  <h2>Why CSS is Better</h2>      

  <p>Style sheets allow you to separate content from its      

     presentation, which leads to pages that are more easily      

     reproduced as templates for other pages and to vastly easier      

     maintenance. Smaller file sizes, fewer place-holder graphics,      

     and faster load times are some of the other benefits of CSS.</p>      

      

  <p>If you have other ideas on this subject,      

     <a href="mailto:dan@danshafer.com">drop me an email</a> and      

     let's talk about it!</p>      

</div>      

</body>      

</html>

Summary

You should now understand the historical and technological contexts in which CSS has emerged, what major problems it is designed to solve, and how it works at a surface level. You should also know why tables are a bad idea as a Web page layout device, even though they have other, perfectly valid uses.

In addition, you can identify both the parts of a CSS rule and at least three ways
of categorizing CSS style rules in general.

Chapter 2 drills more deeply into the prospective issues surrounding CSS. It clears up some of the misconceptions you may have about this technology, and describes some of the important issues you’ll have to take into consideration because of the way Web browsers work (or don’t) with CSS rules.

Read Chapter 3: Digging Below the Surface.

Frequently Asked Questions (FAQs) about CSS