Integrated Web Design: CSS Beyond the Retrofit
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Over the past several years, Web designers have been using Cascading Style Sheets (CSS) to address a range of concerns regarding their Web pages. Most of the CSS in current use is really a retrofit solution to cleaning up pages with cluttered font elements, managing basic text formatting and color, replacing spacer gifs with CSS margins and padding, and creating link effects.
That's all fantastic, but CSS, as we're beginning to find out by visiting such sites as the CSS Zen Garden, is a far more profoundly powerful and useful tool.
An even greater concern is that many designers and developers have inaccurately but understandably blamed CSS and Web browsers for challenges with CSS. The problem at this point may really have more to do with the fact that important concepts in CSS are not explained to us in clear terms. As a result, what might appear to be a browser bug or a fault of CSS might simply be the result of the way CSS integrates with our HTML or XHTML documents, or how the concepts within CSS are resolving conflicts. Without a clear understanding of CSS as a language, and the way it integrates with markup, we're all at a disadvantage if we want to create CSS-based sites that are cross-platform, cross-browser-compliant and also attractive.
Begin with Structure
You've probably read about the importance of separating structure from presentation. To better understand this concern and to feel more confident when using CSS, you have to begin with an understanding of what is really meant by structure and presentation.
Structure encompasses the necessary components of a document plus the logical marking up of the content in that document. Presentation is the way the content is styled. Usually, presentation refers to visual styles, but it doesn't always have to, especially as aural style sheets become more available.
Ideally, you'll separate structure from presentation as much as possible, with the structure in your HTML or XHTML document and the presentation information managed with CSS. The advantages of this are many, but the three most immediate benefits are more efficient document management, faster rendering of documents, and improved accessibility of content.
Structure is found within the HTML or XHTML documents you're using for your Web sites. A huge part of the problem with retrofitting pages with CSS is that those pages have often been designed without structure and logic—they rely on tables for layout, and they do not contain important document information that will help overcome certain browser limitations.
Whether you're using HTML or XHTML is fairly irrelevant to this discussion; what is relevant is that when you build a contemporary site from the ground up in either HTML or XHTML and want to use CSS effectively, you have to have a structured document. This means that you must have all the required elements as well as a logical hierarchy to the way in which your content is managed.
Required Elements within a Document
There are a range of elements that must be present in any document prior to adding content. This is where you find structure at its most basic, and if you don't adhere to these requirements, you'll lose precious control over not only the way the document is displayed, but also how it integrates with CSS.
Required: DOCTYPE Declaration
Surf to a page—any page—and view source. Nine times out of ten, you won't find a DOCTYPE declaration. And even if you do, it may not contain the URL to the Document Type Definition (DTD) to which the document should conform.
A DOCTYPE declaration is a bit of SGML that is required for all conforming HTML and XHTML documents. It declares the DTD (the long laundry list of allowed elements and attributes for that language and language version). The snippet below is a DOCTYPE declaration that declares the document as being one that follows the XHTML 1.0 Strict DTD:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
In the past, DOCTYPE declarations were passive until you attempted to validate the document. In validation, the DOCTYPE is used by the validator to know which language and version to test the document against. However, DOCTYPE declarations have become very important now as a result of technology built into all contemporary Web browsers. This technology is referred to as the "DOCTYPE Switch". When a browser with this feature finds a correct DOCTYPE declaration in your document, it will switch the browser into what is known as "Standards" mode. This mode fixes a lot of problems within browsers, especially Internet Explorer 6.0's improper implementation of the Box Model, which is critical when using CSS for design and positioning.
By tapping into the DOCTYPE switch, your CSS designs will be far more accurate between browsers. So not only should you have a correct DOCTYPE declaration in your documents because the languages of HTML and XHTML require them, but also because without them, you may spend countless hours tearing at your hair and blaming CSS or the Web browser in question for being bad when the problem might be very easily corrected.
NOTE
Read more about DOCTYPE switching at http://gutfeldt.ch/matthias/articles/doctypeswitch.html.
Other Important Elements
The html element is what is known as a "root" element. It is the element from which grows the document tree, which we'll be looking at in just a sec. Within the html element there are two necessary "child" elements: the head element and the body element. Within the head element, you should always include a title element because it is both practical and required by some versions of HTML and XHTML. Listing 1 shows all the basic requirements of a document.
Listing 1-The required components of a structured document.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Working with Structure</title>
</head>
<body>
</body>
</html>
Managing Character Sets
A related concern is defining a character set. Without a defined character set, your document will not be validated by the W3C validator. Character sets can be included in a number of ways. The most efficient is to have the character set in the http headers on the server.
Another more ready means for most Web authors is to include character set information in a meta element. Finally, if you use an XML declaration in an XHTML document, you can include your character encoding information there, but problems exist with this declaration. For more information about this issue, see http://www.webstandards.org/learn/askw3c/dec2002.html.
Logical Markup
After ensuring that your document has all the basic structural requirements, the next important step is to use your markup logically. This is part of structuring content effectively. Many HTML elements have meaning that's more inherent to structure than presentation, and the more we use those elements properly, the better our pages will perform in general, and the easier it becomes to integrate them properly with CSS.
The meaning of an element is what's referred to as semantics in the markup world. An h1 element doesn't mean "Make this text bold and large." It means "This is the most important heading in the document." That a browser will make an h1 appear bold and large when unstyled is not a requirement of the HTML and XHTML specifications; it's merely a convention used by browser developers. The semantic meaning is what's important, not the way it looks.
Another great example of semantics in markup is the use of em and strong elements over i and b elements. If a screen reader used for accessibility encounters em or strong, it knows to pronounce the content within the element in a specific way; whereas using tags for bold and italics has no semantic meaning. Those elements are pure presentation, which is what you're trying to separate out of your documents and into CSS.
Listing 2 shows structured text within a document.
Listing 2-Using semantic markup to describe content.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Working with Structure</title>
</head>
<body>
<h1>Welcome</h1>
<p>Welcome to the site where structure matters!</p>
<h2>Getting Into Structure</h2>
<p>In order to begin working with structure, you need to be aware of:</p>
<ul>
<li>DOCTYPE declarations</li>
<li>Properly structured head and body elements</li>
<li>Logical structures for content markup</li>
</ul>
</body>
</html>
When you have a more semantic document, you can easily visualize it via the document tree, which is a map that reflects where elements go within the structural hierarchy of the document. This tree becomes critically important when using CSS because of the concept of inheritance. Inheritance means that a child of a parent element will take on the styles of the parent element unless another CSS rule is offered or a given style isn't inherited. Not understanding this relationship is one of the areas in which those folks using CSS to patch woes on poorly structured documents can quickly run into trouble: They can end up blaming the limitations of a browser or of CSS rather than realizing that the problem is with a feature rather than a bug of CSS.
Figure 1 shows the document tree that the markup in Listing 2 generates.
)
Figure
1 The document tree produced by the markup in Listing 2.