Since the launch of Dreamweaver MX 2004, I've had numerous opportunities to demonstrate its new features and power to both new and existing Dreamweaver users. As with any product demonstration, it doesn't take long before I'm singing the praises of Dreamweaver MX 2004's newfound abilities to design and render CSS, or Cascading Style Sheets.

Recently, however, a novice user asked a question, which, quite honestly, threw me for a loop. The user simply asked, "Why should I use CSS?" I realized at that moment that while those of us who work with HTML and CSS on a daily basis are intimately familiar with the benefits, many of you are not. Or, at least, you may not be fully aware of all of the benefits that CSS can provide. This article is, in written form, my response to that new user's question.

CSS Beginnings

Before I review some of the many benefits of CSS, here's a bit of history. The governing body of the web, the W3C, recommended the use of CSS in December 1996 with the ratification of the CSS Level 1 specification. CSS Level 1 described attributes for use in HTML pages. These attributes replaced the traditional font tag and other "style" markup such as color and margins. In May 1998, the W3C ratified CSS Level 2, which added additional capabilities to the level 1 specification and introduced positioning attributes. These attributes replaced the rampant (and incorrect) usage of the table tag to design the presentation of page elements. The most recent revision to the CSS specifications is CSS 2.1, which refines some attributes and removes others that had only limited, if any, usages in current browsers.

Unfortunately, as is often the case with new technologies, CSS has been slow in reaching broad adoption. One of the key reasons for this was the browsers, and, in turn, the web designers building sites for these browsers. At the time of CSS ratification, Netscape Navigator (NN) was still the dominant browser, and its support for CSS was basically nonexistent. Microsoft added very limited support with version 3 of its browser, but most web designers at the time (this author included) were still coding their pages with NN as their reference platform.

Over the years, with each new version, the browser makers have expanded their support of CSS. Today, Internet Explorer 6, Netscape Navigator 7, Mozilla, Opera, and Safari all fully support CSS. That is not to say that our lives as web designers and developers are without problems. While all the above-mentioned browsers support CSS Level 2, they still do so with varying degrees of compliance. And, in some cases, certain attributes still give you cause for frustration. In other words, you still need to follow the age-old mantra of "test, and test often." However, if you stick to core attributes of the CSS specifications, your pages will render correctly.

But why did the W3C see the need to create the CSS specification at all? What does it all mean to me as I create HTML-based web sites and applications? Well, in my opinion, you can divide up the need for CSS and its resulting benefits into three main areas: flexibility, rendering, and accessibility.

Flexibility

I'm sure that almost every web designer and developer has experienced that moment of panic when, after meticulously laying out a page—complete with numerous nested tables—the client requests a "small" change. This could be something as simple as "can you move that image a little to the left," or as dramatic as "I'm not happy with those headers, can you make their font larger—and while you're at it, how about changing their color too?" If you're dealing with a limited number of pages, you can take a deep breath and spend the better part of an hour making those irritating changes. But when you are dealing with the larger sites, which have become the norm, a simple change is suddenly anything but simple.

What causes the panic in these situations? The markup, which defines the appearance of our pages, is actually part of the pages themselves. To see an illustration, take any given page from one of your sites and count the number of font and table tags. If only you could remove this markup from the flow, or code, of the actual page—and, even better, if you could externalize it—you could make the changes in a centralized place. Hmm, sounds like a job for CSS.

By designing your pages using a single, or even multiple, external style sheets, you can apply those changes to your site by modifying the style sheet and then simply uploading the modified version.

Imagine how difficult it would be to move your site navigation from the left side of the page to the right in a traditional table-based layout. This would take hours of repetitive and very tedious work. If, however, you had chosen to use the positioning attributes of CSS (more commonly known as CSS-P) to design your pages, a simple change to the "float" attribute or the "position" attribute in the external style sheet would update the page. There's also an added benefit: You've updated every page that uses that style sheet on the site!

Rendering

Since broadband has become mainstream, many developers have stopped considering how much time it takes to render a page in a browser. However, for many of you, it is important to remember that your target audiences still surf the web on dial-up connections. The traditional table-based layout is one of the primary causes of slow-loading pages. This happens because the browser, upon receiving the page from the server, must first examine and "understand" the complex array of nested tables. It must first locate the most deeply nested piece of content and then meticulously work its way back out of the code until it reaches the uppermost container, the body tag. Only after completing this journey is the browser able to begin rendering the content on the screen.

When you use CSS, the browser can immediately begin the rendering process when it receives the content from the server because there is little, if any, actual presentational markup in the page.

There is also a hidden rendering benefit when using external style sheets. In the traditional table-based approach, the browsers must retrieve, analyze, and render each page individually. In other words, the browser is working just as hard at displaying the 30th page in your site as it was when displaying the first page.

If, however, the site uses external style sheets for its presentation, the first page of the site prompts the browser to cache the linked style sheet files that the page uses. This means that all of the subsequent pages in the site using those style sheets will load even faster, since the browser has already cached the style sheets.

The final rendering benefit reminds me of the movie "Amadeus." In the movie, Mozart asks the emperor what he thought of one of his operas. The emperor responds that it was good, but tedious. When pressed by Mozart, the emperor explains that the problem was simply that there were "too many notes." With web design, this can also be a problem—with the notes being actual HTML code. The more code there is, the longer it takes the browser to understand and make sense of the page.

You've all heard the rumors of office applications that write notoriously bad code, littered with extraneous information that has no bearing on the rendering of the page in the document. And even though you, as Dreamweaver users, don't have to deal with this, you can still be guilty of "too many notes." The typical table-based design is a prime example.

When you implement CSS in your designs, you begin to decrease the amount of code the client needs to download. Simply removing all of the font tags from some pages can minimize the amount of code dramatically. And, if you take the step to move to completely CSS-P designs, in many cases, you can minimize the amount of code by 50% or more! Less code equals faster loading pages.

Accessibility

I hear a lot about accessibility these days. Most developers know that they should be thinking about building more accessible sites, but, to a large degree, only those developers who must build sites for government or educational institutions have been forced into actually doing it. When thinking about accessibility, a large majority of developers assume this means that they simply need to add things like alt attributes to their images. But there is actually much more to accessibility, and using CSS can make it easier for you to build accessible sites.

One of the primary issues of accessibility—and one in which CSS use can really make a difference—is in how an assistive technology such as a screen reader "reads" a page. In the traditional table-based world, a screen reader faces an incredible challenge in deciding how to read a page. Think about how confusing it must be for a screen reader as it encounters a deeply nested table—should it read the content, or skip over it? And if it skips over it, how does it get back to the content later?

As you hit a page, you can quickly spot the content on the page that interests you and ignore the navigation or other content at the top of the page. A visually impaired person doesn't have this luxury. He must wait for the screen reader to parse through all of the extraneous information between the top of the page and the content he is really interested in.

Of course, there are techniques to make the screen reader skip the navigation, but these usually require adding links to images in your navigation bar or other content. While these techniques work, they can also be confusing, and other sight visitors can see them as well. Using CSS, you can define completely invisible elements on the page—elements that are invisible to other site visitors and your mouse. The screen reader can use these elements to navigate quickly and effectively through the document.

With CSS and its lack of presentational markup, the only thing that a screen reader encounters is actual content. Additionally, as you design using CSS-P, you begin to concentrate on the actual "flow" of content. You start to consider its logical order on the page.

As you've been reading this document, you followed the "flow" of information. But in that nested table example, if you were using a multicolumn layout, this paragraph could just as easily have been in the upper right corner of the page. And, in that case, the screen reader would have no way of knowing that it should wait until the end of the article to read it.

Using CSS-P, the browser could also display this paragraph in the upper right corner of the browser window, but the paragraph's position in the html of the document would still be right here where you are seeing it if you were to look at the document's source code. This makes for a much better, more accessible experience.

Article courtesy of Greg Rewis | www.adobe.com

Add This Page To Your Favorite Social Bookmark

Users' Comments (0)

Add your comment