Does it take a long time to make simple changes to your Web pages? Are bandwidth charges higher than you would like due to the size of your Web pages? Have you written hundreds of lines of code just to handle browser differences? If so, you might emphasize the appearance of your Web pages over their functionality. Also, you probably spend far too much time ensuring backward compatibility with obsolete browsers.

In this article of my Quality busters series, I'll show you how to shift the emphasis and priorities of your Web site [and use W3C standards like XHTML, Cascading Style Sheets (CSS), and Document Object Model (DOM)] to reduce maintenance time, lower bandwidth charges, and decrease the amount of browser-specific code you write.

A maintenance nightmare

The SHEEP Web team was assigned to enhance the SHEEP customer sales application -- a typical e-commerce site consisting mainly of a product catalog and shopping cart. The first thing the team noticed about the application was that it was very attractive. It presented the company's products in a colorful and entertaining manner. But customer satisfaction surveys repeatedly showed dissatisfaction with the amount of product description and details and the ability to compare products.

The Web team's task was to add more content and product comparisons to the commercial site. As the team worked on the changes, they ran into at least two major difficulties:

1. The code was loaded with tables and small spacer images to achieve the desired layout. It was easy to make typographical errors when adding new rows or columns to display new content. The team only discovered such errors after testing each change on numerous browsers. The complex table layout also increased the time required to determine where to make a change or add content.
2. The application consisted of many hundreds of lines of JavaScript code to compensate for browser differences and add special effects. Unfortunately, the last time this code was maintained was before the introduction of popular browsers such as Firefox®. As a result, it took a considerable time investment to modify the JavaScript code to handle newer browsers.

Back to top

Rethinking priorities

Seeing what they were up against, the SHEEP team's architect notified the project manager that the site's coding was very difficult to modify and that the project would take longer than originally estimated. Out of curiosity, the project manager looked into the history of the Web site to see if there was a particular reason for the site being so difficult. It turned out that the site's two major influences were compatibility and appearance.

The first driving factor for the site was backward compatibility with older browsers. The site was launched during the early days of the Web. As it evolved, and as Web technology advanced, the company added new features. To ensure the largest possible audience, the site was designed to work with all the popular browsers of the time. To minimize the impact of the rapid rate of change in the browser market, the company decided to freeze the site's HTML tags at the level commonly supported by Microsoft® Internet Explorer® 5 and Netscape® 4. It was this level of compatibility that resulted in extra complexity in the layout of pages and the necessity of JavaScript code to add new functionality.

The second driving factor was the consistent appearance of the pages across browsers. The pages were carefully laid out so that a page would appear nearly identical whether shown on Internet Explorer, Netscape, Opera, or any other graphical browser. To achieve this, the pages used numerous nested tables and small spacer images to enforce table cell widths.

With this research the project manager went back to the site sponsors and asked, "Is this compatibility necessary when less than 0.5% of your customers use these old browsers? And, is identical appearance across browsers necessary when you can establish brand recognition in other ways?"

Back to top

Migrate to Web standards

The sales application example illustrates quality issues caused by incorrect emphasis. The quality issues include increased maintenance time from support of obsolete browser versions and increased bandwidth costs from large Web pages that contain browser-specific markup and code. Fortunately, you can easily work around problems like this if you use the World Wide Web Consortium (W3C) Web standards.

Before 2003, the complexity of Web-page design was a consequence of the lack of any standards or consistent HTML implementations. Browsers competed by adding extensions to the HTML language. They also differed in support for JavaScript code and the Document Object Model (DOM). As a result, developers had to invent ways to ensure their Web pages had a uniform appearance across browsers. Techniques for this included pixel-level positioning of images and text using tables, browser-specific client and server code, programming hacks that took advantage of features or bugs in the browser code, and more.

Around 2003, a convergence of standards and browsers that supported those standards started to appear. Starting in 1998, the W3C released Web standards to provide specifications and guidelines intended to bring developers and browser implementations together. Many browsers, such as Netscape 4 and Internet Explorer 5, started to implement portions of the W3C Web standards. But the present-day level of standards-compliant browsers wasn't reached until about 2003, with the release of Mozilla®, Netscape 6, Internet Explorer 6, Opera 7, and Firefox. While none of these browsers perfectly and fully supports the W3C standards, each is close enough to allow developers to code based on the broad standards, instead of browser-specific implementations.

The Web standards in use today address the three aspects of a Web page: structure, presentation, and behavior. A quality aspect, accessibility, is also addressed by new guidelines and legal requirements. I'll discuss each of these in the sections that follow.

Structure: XHTML

HTML is the original Web page markup language. In present-day Web standards it has been replaced by XHTML. With the growing acceptance of XML, the W3C reformulated HTML to be XML-compliant. The result is XHTML 1.0, which is based on HTML 4.0. One advantage of using XHTML is that older browsers that support HTML documents can read and properly process XHTML documents. Furthermore, since XHTML is XML-compliant, an XHTML document cannot have missing tags or incorrectly closed elements -- a problem of many HTML documents.

The Web standards for XHTML define a new mission for the Web page markup language. In XHTML, the markup language is meant to convey content and structure only -- headings, paragraphs, numbered lists, definition lists, and so forth. Presentation aspects have been moved to CSS. An example of this change is the deprecation of the HTML <FONT> tag, among other presentation-specific tags.

Presentation: CSS

The W3C Web standards define two levels of Cascading Style Sheet (CSS) standards -- CSS1 and CSS2. A CSS3 standard is under development at the time of this writing. The CSS standards define a presentation language for specifying the format of a Web page -- typography, placement, layout, color, and so forth.

CSS allows site designers to place the specifications of presentation and formatting in a separate document from the Web page XHTML document. This allows for reuse and reduces the amount of text that must be downloaded with each Web page. Most standards-compliant browsers provide some level of cache support for CSS documents. This also provides flexibility to change one without affecting the other. For example, if several Web pages share the same CSS document, then a change to that CSS document will be reflected by all pages using that stylesheet.

Behavior: ECMAScript and DOM

The third aspect addressed by the Web standards is behavior, which is specified using the DOM and ECMAScript. The Document Object Model (DOM) specifies the representation of Web pages and related browser objects so they can be accessed and manipulated by an ECMAScript program. ECMAScript, which is a standardized version of the JavaScript language, reduces the incompatibilities of the older browser scripting languages such as Netscape's JavaScript and Microsoft's Jscript. With the DOM and ECMAScript, a Web developer can add sophisticated behaviors and processing that enhance the Web experience for users. For example, you can perform field validation on a Web form at the browser rather than on the server.

Accessibility: WAI and Section 508

A quality aspect of Web pages has also been standardized through a set of guidelines and requirements. The W3C established a set of guidelines to improve the accessibility of a Web site through the Web Accessibility Initiative (WAI). The US Government established a set of requirements for accessibility of Web sites through Section 508 of the US Code. Many other countries have passed similar accessibility requirements and guidelines into their respective laws.

The purpose of the accessibility guidelines is to ensure people with disabilities can use Web pages. An interesting side-effect of designing accessible pages is that the pages are more adaptable to mobile devices such as PDAs, cellular phones, among others.

Back to top

Relax appearance requirements

In addition to backward compatibility requirements, the SHEEP team's architect noted that the site was bogged down with code to enforce its appearance across different browsers. This is another example of older ideas in Web site design causing problems today.

For a variety of reasons, early Web designers and site sponsors insisted that their sites appear identical across all browsers. This insistence went beyond ensuring a similar appearance and page readability. It called for pixel-identical positioning of elements and identical font sizes on every page in every browser. Many hours and weeks of developer time were spent tweaking Web pages to ensure this identical appearance.

The question you should ask yourself today is why. What is the advantage of having pixel-identical appearances of Web sites across browsers?

Do users benefit from identical appearance? Not really. Most users are loyal to a single browser, so they'll only see your site one way, anyway. It doesn't matter to them how the site looks using other browsers.

Does identical appearance maintain the company brand? Not especially. A company's brand is established through a combination of styles, colors, use of trademarks and logos, and presentation. A company often alters the appearance of its brand or trademark logos to suit the product. For example, IBM's well known logo comes in a variety of forms -- single color eight line, single color 13 line, three color eight line (as seen on many Thinkpads), icon symbol (with the eye and bee icons), and so on.

It's sufficient to aim for close-enough uniformity across browsers. And, one advantage of using the W3C Web standards is that standards-compliant browsers will show the pages fairly consistently anyway. Using the standards, you can get close enough to a uniform appearance with a minimum of coding, thus, you greatly reduce the amount of code that you maintain.

Back to top

Benefits of Web standards

Space limitations do not allow me to demonstrate everything the SHEEP team must do to reform the sales site using the W3C Web standards. You'll find some articles and books in Resources that address migration to Web standards. When simply considering quality aspects for a Web site, however, migrating to Web standards and relaxing a site's appearance requirements can yield at least three improvements, which I'll discuss now.

Easier maintenance

Listing 1 is a simplistic HTML example of a table-based navigation menu.

<table border="0" align="center" cellpadding="0" cellspacing="0">

<tr valign="top">

<td width="100"><font color="blue" size="-1">Menu item 1</font></td>

<td width="100"><font color="blue" size="-1">Menu item 2</font></td>

<td width="100"><font color="blue" size="-1">Menu item 3</font></td>

</tr>

</table>

Now take a look at Listing 2, which illustrates the same navigation menu coded in XHTML, with the presentation moved to a separate CSS document. (I don't show the CSS.)

<ul id="navigationMenu">

<li>Menu item 1</li>

<li>Menu item 2</li>

<li>Menu item 3</li>

</ul>

Clearly the Web-standards version involves less coding. Also note that use of XHTML reduces problems caused by copy-and-paste editing of large blocks of statements, such as copying an entire <td></td> clause.

Web standards definitely show a benefit for applications that use templates (HTML fragments that are processed by the application to build the final HTML sent to the browser). The simpler statements reduce the chance that you forget to change a template when the HTML statements are scattered over several template fragments.

Reduced bandwidth costs

Listing 1 and Listing 2 show that the Web standards solution is smaller in text size. Some of the references listed below identify a 50% to 60% reduction in Web size and bytes transmitted when migrating from traditional HTML to a Web standards implementation. This reduction results from:

• Separation of presentation attributes from content so you only specify them once
• Elimination of spacer images and other filler constructs to achieve the desired layout
• Elimination of browser-specific coding

Suppose a company used a Web hosting service that charged $1 per month per 1 GB transmitted for the site. With traditional Web page coding, the company transmits 100 GB per month, thus paying $100 per month. After migrating to Web standards, the company reduces the size of its Web site by 50%. For the same customer traffic, the company only transmits 50 GB per month, for a $50 savings.

No more user lock-out

Another benefit of migrating to Web standards is the elimination of browser-dependent code, and worse, user blocking. Some Web sites today still support only a single browser, which is typically Internet Explorer. Sadly, these sites block between 10% and 20% of their potential audience.

Sites coded using Web standards are viewable on obsolete and older browsers, as well as newer ones. While a site might not look fantastic on an older browser -- more like early text-based sites of the '90s -- the content is usable, readable, and accessible. It's simply beneficial to make your site accessible to any user who wants to use it, especially if it's an e-commerce site offering products for sale!

Back to top

In conclusion

Modernizing a Web site through the use of Web standards and relaxing certain appearance requirements can yield significant reductions in maintenance time, enhancement time, and bandwidth usage. A Web standards-compliant site reduces the amount of data transmitted to the browser, which results in decreased bandwidth usage. A modern site also separates page content from presentation, which simplifies server programming by reducing the work associated with content delivery. Using Web standards like DOM and ECMAScript reduces the amount of browser-specific code you have to write and maintain. And, seeking close-enough appearance across browsers instead of identical appearance simplifies the formatting complexity of a Web site.

As a Web site developer, work with a site's shareholders to determine which is more important: the appearance or the functionality of the site. On another dimension, ask which is more important: the format and layout of the site or the ease of making changes as needed. In most cases, you'll find that the answers lead you to use Web standards and relax the site's appearance requirements.

Resources

Learn

• Retrofit your Web pages for wireless compatibility (Brett McLaughlin, developerWorks, November 2005): Make Web pages accessible to mobile devices with standards like CSS and XHTML.
  
  
• XHTML: The power of two languages (Sathyan Munirathinam, developerWorks, July 2002): Explore this introduction to XHTML and learn how XHTML reformulates HTML 4.0.
  
  
• The Web's future: XHTML 2.0 (Nicholas Chase, developerWorks, September 2002): Stay in the know with this article on the changes in XHTML 2.0.
  
  
• Build quick, slick Web sites (Brett McLaughlin, developerWorks, September 2005): Design fast-loading, responsive Web pages with XHTML.
  
  
• Designing with Web Standards (Jeffrey Zeldman, New Riders Press, 2003): See the benefits of migrating to Web standards and look at an example Web-page conversion.
  
  
• Bulletproof Web Design: Improving flexibility and protecting against worst-case scenarios with XHTML and CSS (Dan Cederholm, New Riders Press, 2005): Improve the accessibility of a Web site with these guidelines that use Web standards.
  
  
• Homepage Usability: 50 Websites Deconstructed (Jakob Nielsen and Marie Tahir, New Riders Press, 2001): Delve into fifty case studies in Web page usability.
  
  
• Web Standards Solutions: The Markup and Style Handbook (Dan Cederholm, Friends of Ed, 2004): Sample and explore a cookbook of Web standards solutions.
  
  
• Rapid Web development (James Lewin, developerWorks, September 2001): Create flexible sites quickly using standards like CSS and XHTML.
  
  
• Reap the benefits of these standards in your Web programming:
  • XHTML 1.0 The Extensible HyperText Markup Language: The W3C recommendation (August 2002).
  • Cascading Style Sheets, level 1: The W3C recommendation (December 1996).
  • Cascading Style Sheets, level 2: The W3C recommendation (May 1998).
  • Document Object Model (DOM): A W3C technical report.
  • Standard ECMA-262: ECMAScript Language Specification, third edition (December 1999).
  
  
• Web Content Accessibility Guidelines Working Group: Check out these notes on the W3C accessibility guidelines.
  
  
• Section 508: Read the United States accessibility standards.
  
  
• developerWorks Web architecture zone: Expand your Web-building skills with articles, tutorials, forums, and more that specialize in Web technologies.
  
  
• developerWorks Open source zone: Find extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  

Discuss

• developerWorks blogs: Get involved in the developerWorks community.
  
  

About the author

Michael Russell has a Bachelors Degree in Physics and a Masters Degree in Computer Science. He was a logistics engineer, a technical services manager, and a certified IT architect at IBM for nearly 14 years; he is currently a Web application architect for a resort company in Orlando, Florida. He has experience in Windows, UNIX, and OS/400 environments and uses Web technology for entertainment through his own company, Vicki Fox Productions.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• A maintenance nightmare
• Rethinking priorities
• Migrate to Web standards
• Relax appearance requirements
• Benefits of Web standards
• In conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Web development on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers