File Under: CSS

Update Your Old Site to Use Web Standards


Web standards? You can’t afford to ignore them anymore.

Just two years ago, coding your site to the emerging guidelines from the World Wide Web Consortium was next to impossible. After all, many surfers were still saddled with browsers from the days when Netscape and Microsoft deliberately built incompatible products.

But now, thanks to outspoken advocates such as the Web Standards Project (aka WaSP) and developers who refused to choose sides, browser makers have stopped using HTML as a weapon. Today’s browser offerings are more and more alike in their support of standards such as CSS and XHTML. Microsoft and AOL-Time-Warner-Netscape seem to have taken their battle to lock up consumers elsewhere.

The change comes just in time:Most sites’ million-dollar boom budgets have been cut to as low as a few thousand bucks. According to the WaSP’s official estimate, supporting incompatible browsers adds an average 25 percent to site budgets. So maintaining different code for two, three, or more browsers is no longer an affordable option.

Instead of trying to support multiple versions of the same pages, it’s much more cost-effective to piggyback on the millions of dollars Microsoft, Netscape, Opera, and others have spent building standards-compliant browsers and just stick to using standards-compliant markup on your site.

If you don’t, you may be relying on bugs instead of features to deliver the goods. They won’t work forever. And by focusing on specific browsers instead of one syntax that works for all of them, you may be locking out surfers with alternative Web gadgets or special technologies, such as talking browsers for the blind.

Still, times are tough. As one developer said, “Try telling your boss about standards when she just found out her accounting firm didn’t have any.” With that in mind, here are three simple, fast, cheap things many sites can do to come up to speed on standards and make your site less costly to maintain.

The first:One line that makes all the difference in the world.

Contents

  1. Put a DOCTYPE Atop Every Page
  2. Use Those Validators
  3. Move Presentation Tags into CSS
  4. An Immodest Proposal:Dump 4.x Browsers Now
  5. Free Consulting

Put a DOCTYPE Atop Every Page

Many developers still don’t realize that newer browsers look for a DOCTYPE at the top of each page, and will change the way they behave in response to it. Without the correct DOCTYPE, browsers can take your standards-compliant page and render it all wrong.

This is true for Internet Explorer 6.0 on Windows, Internet Explorer 5.0 and later on the Mac, and all Mozilla-based browsers including Netscape 6.0, Compuserve 7.0, and in the future, maybe even AOL 8.0.

DOCTYPE describes the document type definition to which the markup that follows it conforms, for instance “XHTML 1.0 Transitional.” It includes a link to a machine-readable document type definition (DTD) file.

If one of the above browsers sees the right DOCTYPE at the top of the page, it will follow the corresponding behavior as best it can. If the DOCTYPE is not there, or isn’t formatted properly, the browser reverts to a backwards-compatibility mode, behaving like its quirky late-1990s predecessors to support old Web pages created for older browsers. Mozilla will even switch to compatibility mode if the DOCTYPE lists HTML 4.0 or earlier (as opposed to 4.01, which it handles normally).

Check your DOCTYPE carefully, because if there are any typos, it won’t generate an error message – the browser will just switch from standards-compliant mode to bug-compatible mode as if there were no DOCTYPE at all.

Even if you already see a DOCTYPE on your page, check it carefully. Dan Tobias warns that some WYSIWYG editors insert incorrect DOCTYPEs automatically. And smart developers (I’ve done this) sometimes cut and paste example DOCTYPEs from W3C pages without realizing they include relative pathnames at w3.org. They don’t work on other sites, but they don’t cause an error message either.

Which DOCTYPE to Use?

HTML 4.01 Transitional is what you should use if you have any doubts. It works right with all new browsers and most old ones in use. It’s what I use on my homepage and weblog.

XHTML 1.0 Transitional is more complicated, but will give you a leg up on the future.

There are DTDs for earlier versions of HTML and future revisions of XHTML, but most sites shouldn’t be using them.

Rather than describe how document type definitions work, let’s just list the correct versions for the most popular current and near-future standards developers are coding to – HTML 4.01 and XHTML 1.0, which defines HTML as an XML application.

HTML 4.01

Transitional

Use this one if in doubt. It supports most of the old Netscape and IE extensions to HTML, so it works on most existing Web pages.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Strict

No presentational tags or attributes (such as FONT) allowed, because those should be in stylesheets instead – we’ll get to that in a minute.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Frameset

For framesets only. Use Strict or Transitional for the individual frames inside the frameset.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0

Use these to start planning for the XML-powered future today. Your site may not need much retooling – XHTML is just HTML defined as an XML application.

Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"></font>

Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"></font>

Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"></font>

Once you’ve got the right DOCTYPE at the top of every page, you’re ready for the second (and second-easiest) standards step:Validation.

Use Those Validators

They’ve been around for years, yet I still meet senior coders who’ve never used a validator.

Validators check the syntax of your HTML and CSS to make sure it is correct, and let you know about any errors or ambiguities. It’s up to you to figure out how to fix the errors, but usually the mistakes are fairly obvious.

The cost-cutting angle to validation is simple:Any part of your site’s design that requires invalid markup to make it lay out properly should be redone. Nonstandard behaviors you rely on might stop working with the next Windows security patch.

The W3C HTML Validation Service

If you have the right DOCTYPE atop your page, typing its URL into the form on the validator’s front page will generate a report listing syntax errors in the page, as specifically compared to the definition in the DOCTYPE. For example, running my weblog through the validator finds these tags that aren’t in tune with HTML 4.01:


 * Line 130, column 18:



     </script> </head>



                    ^



Error:end tag for element "HEAD" which is not open; try removing the end tag or check for improper nesting of elements



 * Line 131, column 50:



   ... "#4B0082" link="#00008B" text="#000000" topmargin="5" leftmargin="5" m ...



                                               ^



Error:there is no attribute "TOPMARGIN" for this element (in this HTML version)

 

Usually just looking at the source will reveal the problem quickly – a missing tag, a typo, a nonstandard element or attribute. Don’t get intimidated if you get a long screenful of errors. Fix the first one shown, the run the page through the validator once gain. Often one fix will cause a lot of the other errors to disappear.

W3C CSS Validation Service

Once your HTML passes the test, check your stylesheets next. The CSS validator is flexible about input:You can either feed it a URL (the W3C people call them URIs instead of URLs, but I’m a populist), paste your stylesheet into the page, or just upload a CSS file to it.

Bobby Accessibility Validator

[/webmonkey/design/site_building/tutorials/tutorial5.html Accessibility standards] are different from syntactical standards, but they’re becoming more and more important. Advocates often cite the potential cost of lawsuits, but it’s also my experience that sites designed to work for people with disabilities are more usable in general, and easily transfer to other formats (e.g., handhelds) because they don’t rely on color or images to convey their information.

Bobby will test your page against the W3C’s Web Content Accessibility Guidelines for surfers with disabilities, as well as Section 508 federal requirements for US government websites.

Besides checking images for ALT text, Bobby raised less obvious questions about my site, such as these:

If you use color to convey information, make sure the information is also represented another way. (35 instances)

Lines 132, 137, 140, 141, 142, 149, 151, 162, 165, 167, 183, 185, 196, 198, 210, 212, 222, 225, 226, 228, 230, 300, 302, 331, 335, 337, 366, 367, 369, 371, 375

If this is a data table (not used for layout only), identify headers for the table rows and columns. (3 instances)

Lines 147, 236, 365 Bobby also asked me, “If style sheets are ignored or unsupported, are pages still readable and usable?” I think Bobby read my mind about our third and final fix.

Move Presentation Tags into CSS

While checking sites for correct DOCTYPEs, I found a surprising number of pages that had stylesheets, yet were full of complicated FONT tags and tables. Of course, the maintenance costs of having FONT tags everywhere (even if you write a Perl script) is much higher than moving them once and for all into CSS.

A core concept behind the development of stylesheets and the document object model (DOM) was the separation of a site’s content, presentation, and behavior from each other. Content should be handled by HTML, presentation by CSS, and behavior by the DOM. But many sites still mix content and presentation by peppering their pages with FONT tags.

CSS got a bad rap for being buggy in the first browsers that supported stylesheets, but things have changed a lot. Even Webmonkey’s cousin, Lycos Europe, is working on an XHTML/CSS prototype of its uberportal that looks like tables, yet it’s all done with stylesheets.

Check out the source and note how much easier the CSS and HTML will be to maintain compared to the current Lycos Europe site, which mixes tags and stylesheets in the same page. Cleanly separated content and presentation mean Lycos will be easier to port to new gadgets like phone browsers, yet the page still works on Internet Explorer 4.0.

Printer-friendly Pages Made Easy

CSS can take a few weeks to learn, but the payoffs in time saved are worth it. My favorite is the automatic printer-friendly format, something many news and magazine sites seem unaware of. It’s part of the CSS standard, honest:Instead of creating an entirely separate printer-friendly page template, just optimize your standard layout stylesheet to look its best on paper. That could mean changing fonts and colors, or even removing ad banners while leaving the company logo, as in Eric Meyer’s example. Then put both stylesheets in the regular page, with one defined for screen media and one for print media, like this:

<LINK rel="stylesheet" type"text/css" href="screen.css" media="screen">

<LINK rel="stylesheet" type"text/css" href="print.css" media="print">

The browser will use the right stylesheet automatically when it sends the page to a printer. Codestyle’s table shows that version 5.0 and later of Navigator and Internet Explorer on both PCs and Macs support print styles, as does Opera.

In fact version 4.x browsers are the last remaining hurdle to chucking the bulk of the wacky, old browser-specific markup for most sites. When I talked to the Web Standards Project for this article, I wasn’t surprised when its ringleader proposed a controversial but obvious way for developers to increase standards compliance and cut a big chunk of their maintenance costs at the same time:Simply dump all 4.x browsers.

An Immodest Proposal:Dump 4.x Browsers Now

According to TheCounter.com, the number of surfers using Netscape 4.x or Internet Explorer 4.x browsers dropped to just five percent in June 2002. That’s two percent fewer than the month before, and one-third last year’s levels.

Yet supporting these Browser War relics is, according to both the WaSP and independent developers I talked to, a major drain on time. It’s also the last roadblock to moving to a clean (X)HTML/CSS architecture. Many companies still use Netscape 4.7 as the supported standard on employees’ desktops, because upgrading would be expensive and time-consuming.

WaSP cofounder Jeffrey Zeldman suggested an obvious fix:Move your presentation information into CSS, then treat 4.x browsers if they don’t do stylesheets – serve them simple HTML text instead.

The WaSP site uses a simple trick to keep its stylesheets away from 4.x browsers. Instead of calling stylesheets using the 1997 syntax …

<link rel=StyleSheet href="/css/style.css"

 type="text/css" media=screen>

… the WaSP site uses the newer format, which 4.x browsers ignore:

<style type="text/css" media="all">

 @import "/inc/css/wsp.css ";

 </style> 

There are ways to hide stylesheets from other buggy browsers as well.

The Browser Upgrade Campaign

Zeldman’s newly revitalized WaSP relaunched itself this spring with an all-star cast. Both of Zeldman and XML-guru Tim Bray told me in a recent interview that the WaSP’s next step is to take the standards message to developers and toolmakers.

The WaSP has already launched a Browser Upgrade Campaign that asks site builders to automatically alert visitors with noncompliant browsers to a list of suggested upgrades, without resorting to locking them out.

You may not agree with everything it has to say, but the WaSP is definitely making us reconsider our options and assumptions now that the bad old days of incompatible browsers are gone.

Free Consulting

Web standards are much too complicated to explain in a single article, especially once you start exploring accessibility issues. The sites and books below are mostly by WaSP members or were recommended by them. The authors specialize in explaining and clarifying XHMTL, CSS, and more for people who want to get results, not tinker with protocols. A few minutes with these books have often ended hours of frustration for me – over such simple matters as my broken DOCTYPE tags.

Handy Reference Books

Payback Time

With the Nasdaq lower than my SAT scores, you might think it’s a bad time to think about retooling your site to get rid of nonstandard code and special-case hacks for buggy browsers. But take a serious look at how much time you spend supporting old code or old browsers, and you may find that adding a few DOCTYPE tags and running the validator will help rather than hurt your budget.

It’s not fiscal magic:Developers are finally getting a payback for five years of bitching and moaning about standards. Most surfers now have free software developed, at great expense, by Microsoft and AOL Time Warner to meet emerging standards for interoperability and accessibility. By developing your sites to the same standards you demand of their browsers, it’s only natural that you could save yourself time and money … not to mention a lot of headaches.