The Dollars and Sense of Building to Standards

In: Columns > The $ & Sense of IT

By Alan K’necht

Published on February 9, 2005

Since people like Jeffrey Zeldman started persuading browser manufacturers to support standards through the Web Standards Project, browsers have come a long way.

While there may be no official standard for how Web developers code Web sites, we need look no further than the World Wide Web Consortium (W3C) for some recommendations. Only by following these guidelines can Web developers ensure the maximum return on investment for Web site development. And when it comes to standards, we need to start saying goodbye to our love/fascination with ancient HTML 4.01 and tables, and say hello to XHTML, CSS and the use of divs.

So why has it taken so long for Web development standards to become a reality? Why have Web front-end developers ignored them for so long? Simply because the browser manufacturers let them get away with it—and it made coding much quicker when we didn’t have to think about details like the closing paragraph tag.

For the purpose of this article, think of standards as a guide to writing valid code.

All traditional software programmers have always needed to validate their code, usually through a compiler. Yet, as Web developers, most of us simply use a browser for validation: “It looks good in browser X so it must be valid.” In reality, to ensure your code is valid (follows standards), you need to run your HTML through a HTML validator. My favorite is hosted by the W3C and can be found at http://validator.w3.org.

So why should you be adamant about valid code and pushing for more Web development using XHTML? That’s easy. It costs less and is more flexible.

Your clients (external and/or internal) are going to ask, “How much is this standards thing going to cost me?” and “What’s in it for me?” when you start to talk about standards.

Browser statistics from w3schools.com (November 2004)

Browser	% Traffic
IE 6	69.1%
Mozilla	18.6%
IE 5	5.0%
Opera 7	2.3%
Netscape 7	1.3%
Netscape 3	0.2%
Netscape 4	0.2%

People simply don’t recognize how much it’s costing them not to code to standards. For too long, people have accepted poor HTML code and assumed there was nothing that could be done to improve it.

Let’s start by setting the record straight. First, one of the problems has always been that browsers don’t support standard functionality as defined by the W3C. Fortunately, since the release of Netscape 6.0, Opera 5.0 and IE 6.0, browsers have supported most of the functionality defined by the W3C (up to and including strict XHTML). Unfortunately, users around the world have been slow to upgrade to these newer browsers.

Yet, with growth of Windows XP and the adoption of Mozilla Firefox, use of older browsers is dropping rapidly.

These will vary according to the target audience of a Web site. Check your access logs.

HTML 4.01 or XHTML?

When it comes to building Web sites to standards, there are two things to consider. First, can you say goodbye to HTML 4.01 and hello to XHTML?

For your answer, take a peek at your access logs. Your logs will tell you which browsers your visitors are using. If Netscape 4.7 and IE 4 usage is nonexistent, the answer is yes. If they still represent a small amount of your visitor traffic, then it’s a business call. Ask yourself:

• Do outdated-browser users represent a significant portion of my traffic?

And more importantly:

• Do they represent my target customer?

Or better yet (in case of commerce sites):

• Do they represent the people who are buying my product?

If your answers are generally no, you’re ready to move on. If you’re saying “yes,” you need to decide if it is sufficient that users of older browsers see something that looks different, then develop a migration strategy. If you’re still stuck writing HTML 4.01, then at least start writing valid HTML 4.01.

The good news is that if you’re ready to embrace XHTML (either Transitional or Strict), there are numerous savings to be had which will increase the ROI of your next Web project. It will also make future updates easier and bring your Web site into the modern world of Web development.

But before you go out and start coding XHTML, you need to define your audience (see above). Once you know this, you can draw a line in the sand and say, “We’re only going to design for X version and above of browser Y .”

You may find some resistance within the organization to dropping support for a particular browser. Remind the resistance that there is only a handful of people, if anyone, still building and testing Web sites to work in IE 3.0 and Netscape 3.0 and at some point in the past support was dropped for these browsers. This is the natural evolution of the Web.

Improved ROI through XHTML

You’ll start saving money as soon as you make the business decision to switch to XHTML. How much depends on many factors.

A significant portion of any Web designer’s development time is spent ensuring that code works and looks right in a broad range of browsers. If your organization is in the advantageous position to drop support for Netscape 4.7 and IE 4 and 5, you can expect a time reduction of anywhere from 15-35% in the HTML development phase of Web development. This equates directly to significant dollar savings.

Another way to save money even if you can’t drop support for Netscape 4.7 and IE 4 is by coding to standards that older browsers support.

One complaint I hear when I recommend this is, “But the site will look different on different browsers!” My answer is always, “So what? How many users are using two different browsers at the same time and comparing what the site looks like in both of them?”

The question the business needs to ask is, “Does the site still look good?” and “Can the user still effectively use the site?” If you can answer yes to both of these, then don’t waste your time trying to get it to look exactly the same on all browsers. If the answer is no, go back to the visual design and change it so it can work across all browsers. There is no need for a Web site to reflect a printed brochure to smallest detail. One is paper and the other is electronic. By accepting this reality, you can expect savings of 5-10% in your HTML development phase.

Improved ROI with CSS

Another benefit of coding to standards occurs when a Web developer opts for the use of cascading style sheets. Even when used to their limited functionality in Netscape 4.7, a developer no longer has to worry about correctly defining every bit of text in terms of color, size, typeface and positioning. This is done once in the CSS. Then when management says, “I want this bit of text to be navy instead of light blue everywhere in the site,” you only need to change one file (the CSS). No need to do a find-and-replace over hundreds of files and test the entire site to ensure that nothing was broken in the process. How much time will this save you? That depends on how often you are faced with these kinds of changes.

I recently had to put this feature to practical use. A Web site I was technical lead on was less than a week away from the launch of a major redesign. The site was completely redesigned, but the firm overlooked my suggestion that the design agency had made the type too small. At the completion of user acceptance testing there was one clear common complaint: “The type is so small, it’s hard to read.”

Fortunately, the site was designed using valid XHTML Transitional and all type definitions were contained in external style sheets. Instead of manually changing more than 800 files and retesting to make sure all pages had been changed correctly, a single edit was made to the base font to increase it by 2%. This change cascaded to all the type definitions and the easier-to-read site was available in less than 10 seconds. This equated to virtually zero cost. If the site had been built the old-fashioned way, it could have reached into the thousands of dollars (including all testing costs) and delayed the launch of the redesign.

Reduced development times

While there are many ways that coding to standards saves the organization money, one of the most overlooked savings is reduced uptime for a new employee. Let’s face it—no one is an employee for life anymore. With high turnover in the industry, having a standard way of doing things is important to every organization. Think about the last time you had to pick up some HTML/XHTML code that someone else wrote. How long did it take you to review it, clean it up the way you like it and then start working on it? When a new employee joined your organization, how long did it take them before they were up to speed on the way the organization said the pages should be coded? If everyone was trained and followed the standards, how much easier and faster would it be for you to fix a Web page that you didn’t write or to indoctrinate a new employee? This equates to big savings.

Better search engine rankings with XHTML

While the jury of search engine experts is still out on this, I believe that by coding a Web site in XHTML and moving all positioning elements to the CSS, you can increase your site’s ranking in search engine results.

This is accomplished a few ways. First, reducing (improving) the ratio of content to code on a Web page makes the message of the page clearer to search engines and will help with ranking.

Second, by organizing content by priority in your HTML and leaving its screen position to the CSS, you are showing the search engines what part of your page is most important. The use of CSS further allows you to effectively use H1 and H2 tags to further demonstrate the important elements of the page content.

For more information, see SEO and Your Web Site.

Reduced time to support alternative browsers and devices

With the growing use of alternative devices and browsers, XHTML Strict and valid CSS are becoming even more important. By detecting what device or browser is accessing your Web page, you can reformat the entire content on the fly with a simple style sheet definition instead of developing a unique site for each device (handheld, WebTV, etc.). This translates into enormous savings to the organization and allows for faster deployment.

Don’t think people are using alternative devices to access your Web site? Do people print pages of your Web site? A printer is not a browser and even a site designed with a static width of 800 pixels won’t look right on an 8.5″ by 11″ piece of paper. The solution is to have a style sheet for printers (just as Digital Web Magazine does).

It’s time to push for standards

Ultimately, the push for standards-compliant code should come from the coding ranks. We need to enlighten all levels of management to the savings they can achieve by embracing Web standards. If the people on the front lines don’t take on the job of promoting standards to management and management learns of these savings first, you’ll be faced with a tougher challenge—why didn’t you know to use and push for standards-compliant code?

For more ammunition in the fight for Web standards and some cool coding tips, visit the Web Standards Project. These people are fighting on behalf of all of us to achieve standards compliance in all browsers and Web development tools.

Related Topics: Web Standards, Browsers, ROI