Tutorial

Should you even care about standards? Given that Microsoft’s Internet Explorer product for Windows is now the dominant browser, perhaps you think that standards do not matter anymore—you’ll just code your pages for IE and be done with it. But to confuse matters, while IE5 for the Mac proudly boasts of the number of standards it supports, the new 5.5 beta version of IE for Windows has introduced a whole slew of proprietary features rather than concentrate on shoring up standards compliance. Just choosing to support one browser may be the easiest thing to do in the short run. However, if web programmers and designers actively show their support for browsers that are standards-compliant, it’s ultimately going to make our jobs easier.

Most conscientious designers and developers currently spend a lot of time checking and re-checking their pages across a variety of browsers, painstakingly weeding out and fixing things that break on one browser or another. The vision of organizations such as the Web Standards Project is to someday have an ideal world where browsers all support a set a base set of features so that we no longer have to waste our time seeing if a page works in one browser and not in another. You may have even chosen to sit on the sidelines so far when it comes to technologies such as CSS and Javascript, coding your pages on the more firmly established base of HTML 3.2 to avoid problems. Now imagine that all the “cool” things you see on the more adventurous sites are fully stable and viewable on a wide variety of browsers and platforms. Imagine how much more creative and functional all the sites you create can be. But as with all worthwhile quests, the way is paved with many obstacles and tests of endurance. In essence, as the browsers become more standards-compliant, it becomes necessary for web designers and developers to educate us about standards and get rid of some old habits too.

The purpose of this tutorial is to start you off on that educational process and to help you to get into the right frame of mind to adapt to the new browsers—and hopefully to ease your pain a little along the way. Part 1 deals with HTML and CSS and weaning yourself from past sins. In Part 2 we will look into Javascript and the Document Object Model (DOM). Also for the sake of simplicity the focus is on Internet Explorer and Netscape Navigator ¹.

Step Back, Step Forward
Say what you will about Microsoft, at least in one respect they have made the jobs of web programmers and designers easier for the moment, because they have built in a lot of backwards redundancy in their browsers. This was not so hard to do after all, since the 4.x version of IE already had quite a lot of the critical functionality that all together is termed Dynamic HTML. To put it in a nutshell, in most aspects IE 4 was eons ahead of Netscape in terms of scriptability. On the other hand, Netscape has effectively abandoned all of their proprietary features. It’s better to think of Netscape 6 as being a totally new browser with just about nothing in common with Netscape 4. While most correctly coded pages that work in IE 4.x won’t break or stop functioning on IE 5, even on the stricter Mac version, pages coded to work specifically for Netscape 4.x will fail miserably on Netscape 6. But instead of regarding that as an obstacle let’s try to think of it as a good opportunity to progress to the next level.

One more word before we move on. Whenever a certain feature doesn’t work on one type of browser, I commonly hear less experienced web designers/programmers blame it on the browser, while more often than not the problem really lies in the use of proprietary code, and the page creators’ incomplete understanding of what is proprietary and what isn’t. Before you decide to use a new, cool feature in one browser, check to see how, or if, the same feature is supported in other browsers. When you do decide to use a proprietary feature, do so with open eyes and with the understanding that the user experience will not be uniform – and make sure your client understands this too.

The goal here is to make pages that are uniform in appearance and functionality across the largest number of browsers as possible. This means making pages that follow the standards. So let’s see how to take your first cautious steps towards standards-compliance.

Clean up Your HTML, Even if You Didn’t Hand Code It
A common feature of standards-compliant browsers is that they are much stricter about syntax. The version 3 and 4 browsers, not to mention IE5/Windows, allow for quite a lot of sloppy HTML coding. This will not be tolerated in IE5/Mac or Netscape 6. When a page breaks horribly in one of these browsers, before you start blaming “bugs” in the program, take a look at your HTML. First of all, do you know what well-formed markup looks like? If not, now is a good time as ever to start learning. Here are some common “sins”.

1. Using open <P> tags to create line breaks. Use <BR> instead. Unclosed tags of any type. Most commonly with <FONT> and other font-styling tags such as <I> or <B>.
2. Overlapping tagged elements, e.g. <P>text<B>more text </P></B>. Most commonly seen in complicated table-based layouts.
3. Mish-mash of HTML attribute specifications with styles. Here’s an example I’ve seen recently:
   <FONT STYLE=”font-size: 9pt” FACE=”Geneva,Helvetica,Arial,Sans Serif” SIZE=”-1″></font>
   Any of these errors, especially the top two, may cause your page to break or even in some cases crash the browser.

The best way to check your syntax and to train your eye and brain to seeing clean HTML is to run your pages through an HTML checker. There are two types of checkers: lints and validators. A lint generally compares your code against the DTD (document type definition) you’ve specified in your page with the DOCTYPE (see below)—or against an HTML4.0 “loose” DTD if you haven’t specified one—checks for common errors, and cleans up your HTML markup. The best one of this kind is probably HTML Tidy by Dave Raggett, which will also perform its magic on XML. I highly recommend getting the port of this wonderful program for your development platform. I use the BBEdit plug-in version ported by Terry Teague all the time—it’s quick and thorough. Even though BBEdit has a built-in lint (the Check Syntax function), the Tidy plug-in does a better job of picking up errors, including any embedded CSS, and best of all, outputs a cleaned up page automatically. HTML Tidy also will check your page for accessibility, following W3C guidelines.

The second type of checker is called a validator. Validators will more rigorously test your page against the specified DTD and report back any errors to you. Currently there are two online validators—the W3C HTML Validation Service and the similar service from the Web Design Group, which also offers an shareware offline version for Windows called A Real Validator.

What if you don’t write HTML directly but use a WYSIWYG program—or generate pages from a word processor? Unfortunately, auto-generated code from the currently available versions of programs is not always valid. As an example, run this GoLive page through a validator: it will return many errors, and in HTML4-compliant IE5/Mac does not display as intended. In particular, if anyone has been adding some handwritten markup or scripts on top of the auto-generated code, chances are that coding errors abound. So as a final step prior to publication, you should run always your pages through a validator regardless of the way it was authored.

Clean Up Your CSS
CSS support in the version 4 and 5 browsers, in general, has so spotty and confusing that you’ve probably been using a strictly trial-and-error method, and you may have picked up quite a few bad CSS coding habits along the way. On the new browsers, invalid CSS may break your page just as invalid HTML will.

Again, help is at hand in the form of CSS checkers. My preference is for CSS Check by the Web Design Group, but the W3C CSS Validator works just as well. Here is a screenshot of some typical error messages returned by CSS Check on a style sheet I uploaded. While none of the errors shown here would actually break a page, it’s a good idea to clean them up anyway. As with HTML checking, CSS checking is an excellent way to educate yourself without having to memorize all the W3C documentation in one big gulp. While you are at it, also try to familiarize yourself with the cascade order of styles.

An important authoring tip is to keep your styles separate from your HTML, either embedded in your page or in an external stylesheet for ease of checking and debugging.

Use the Right DOCTYPE for Your Page
As a final step to ensuring your pages will not break, it’s important to specify the correct DOCTYPE to point to the right DTD (document type definition). Up until now, you’ve probably either omitted the DOCTYPE line altogether or just let whatever your HTML-editor inserted be the DOCTYPE. This is because so far the browsers haven’t really used the DOCTYPE in any meaningful way. However, the standards-compliant browsers will actually use the DOCTYPE to see how the page should be displayed. If you aim towards following the standards, try to make pages that are as clean and well-formed as possible, specify a strict DTD and then view them in IE5/Mac or Netscape 6. An excellent tutorial on how the DOCTYPE specification works is here. The goal is to internalize what well-formed markup and correct CSS syntax is. Once you have done this, not only can you spot and correct errors but it will also become much easier to distinguish between proprietary and standard code.

Get Rid of the Table Cell Mentality in Design
The introduction of tables as a way of controlling the layout of pages was in some ways a curse as well as a blessing. It gave designers, especially those who came from the print world, the false illusion that elements on a web page could be controlled with the same pinpoint accuracy that a DTP page layout could be. With the advent of CSS, many designers have assumed that that pinpoint control would be now easier to achieve. Therefore, it’s quite common to see table-based layouts combined with CSS.

However, this can cause problems on standards-compliant browsers. This comes partly from the fact that tables were never really intended to be used as layout devices, and partly from an incomplete understanding on the part of designers about CSS elements, especially block elements. Tables are so familiar to most designers that they will probably continue to be used for some time, but, as a general rule of thumb, be extra-careful about overlapping tags when you are using tables for layouts. Either completely wrap a table with a block element (such as DIV), or enclose a block element in a single-table cell.

But more important perhaps is a basic mental adjustment about exactly how much you should control on a web page. While some elements, such as tightly spaced navigational items, must be specified in absolute terms (i.e., pixels) as the new browsers allow you to transition into more reliance on CSS, try to get rid the absolutely specified table-cell way of thinking. CSS elements are far more fluid and flexible. It’s time to think in terms of fluidity in your design as well.

Don’t Rely too Much on the Browsers
It’s hard to just stare at code—designers need visual feedback. But it should be clear by now that the currently available browsers are for the most part not reliable as vehicles for standards-compatibility testing. The first step is to concentrate on the steps outlined above, to educate yourself.

There are a couple of browsers that can be safely used for testing your standards-education efforts. On the Mac, IE5 is a stable and worthy testing browser with only a few minor problems. On Windows, however, you can’t really rely on IE5 except for testing some DOM issues. Therefore, I recommend that you download both Netscape 6 Preview Release 1 or a stable-as-possible Mozilla build, as well as Opera 4.0 beta.

Coping with Netscape 4: Getting rid of the <LAYER> and <ILAYER>
The one major proprietary object that will no longer be supported is the LAYER object in Netscape 4. Instead, CSS-positioning will be used exclusively in Netscape 6. If you have many pages coded with the LAYER object, you have two choices, either direct Netscape 4 users to those pages through browser detection and branch other users to other pages: follow Netscape’s recommendation and enclose all non-NN4 code within NOLAYER tags; or get rid of the LAYER tags and replace them with equivalent CSS elements instead. The last option is most recommended, since most LAYER attributes have CSS equivalents. And from now on, eliminate LAYER and ILAYER from your HTML vocabulary and use CSS objects such as DIV instead.

Here is a typical LAYER to standards-compliant DIV conversion:

<LAYER id=”l4″ position=absolute bgcolor=yellow top=103 left=117 visibility=show z-index=2 width=100 height=180 onMouseOver=”someaction”></LAYER>

<DIV id=”l4″ style:”position:absolute; background-color:yellow;layer-background-color:yellow;top:103px;left:117px; visibility:visible; z-index:2; width:100px; height:180px;”></DIV>

Note some key differences. Netscape 4 allows for positioning and size attributes to be set as numbers, but this is incorrect CSS. (Incidentally, the layer-background-color attribute is not correct CSS—it’s workaround in order to display the background color for the block element as intended in NN 4.)

Some features of the layer object are not supported in NN 4 for CSS positionable objects. You cannot associate a Javascript event to the object itself (by specifying it in the tag), and you also cannot import external HTML. The good news is that in Netscape 6, the former will be possible with CSS elements, and for the latter the IFRAME object will be supported as it is now in IE 4/5. For the moment, try not to associate a Javascript event directly to a CSS block element, but rather to an object within the element such as IMG or A, and if you must import external HTML into your page, use the LAYER or ILAYER with an IFRAME wrapped within NOLAYER tags.

It’s also not possible to address the attributes of CSS elements in Netscape 4 directly using Javascript, with the exception of positioning (x, y and z) and visibility. If you have pages where this is crucial, then your only choice is to make a separate page for NN4 viewers, but more will be said about this in Part 2.

Wrap-up for Part 1
If you’re already taking the steps listed above, congratulations! If not, start now before the rush. It’s necessary to put your house in order before you can invite in new elements, and it never hurts to have squeaky clean code.

In part 2, we’ll discuss browser-branching strategies, Javascript interaction with your newly refreshed HTML and CSS, and the new world of possibilities that standard DOM support will bring to your creative toolbox.

Further Resources
Books:
Dynamic HTML: The Definitive Reference by Danny Goodman (1st edition, O’Reilly 1998, ISBN:1-56592-494-0). It only covers up version 4 browsers but is a must in any case if only for the exhaustive reference list. But the tutorials are also excellent.

Cascading Style Sheets: Designing for the Web by Håkon Wium Lie and Bert Bos (2nd edition, Addison-Wesley 1999, ISBN:0-201-59625-3) Covers CSS1 and 2. The authors wrote the official specifications.

DHTML for the World Wide Web: Visual Quickstart Guide by Jason Cranford Teague (Peachpit Press 1998, ISBN: 0-201-35341-5). An good beginner’s guide to CSS, also touching on the proprietary DOMs for NN4 and IE4/5 and Javascript.

Online resources:
World Wide Web Consortium The source. Besides the validators and the official specifications, has excellent tutorials such as Dave Ragget’s guides for HTML and styles and resource lists such as the CSS learning page

Web Standards Organization If you care, join. The mailing list can be quite informative, often combative.

The Web Design Group A more accessible site for information and tutorials than the W3C with an equally strong focus on standards compliance.

CSS Bugs and Workarounds from the CSS Pointers Group Now, imagine a world where you no longer have to deal with this. You might even regain a social life. What better reason for pushing for standards support?

Footnotes
¹ Opera hasn’t had enough of a history yet to worry about backward-compatibility, so the assumption is that whatever current version is out (as of this writing, it’s 4.0 beta) is as fully compliant as possible. However, the documentation for Opera on their site is so sparse that it’s impossible really to know exactly which part of what is supported, even though they do claim support for CSS1 and 2, XML, ECMAScript and JavaScript1.3 among other things. But it’s still a must for testing purposes until a stable Mozilla (Netscape 6) build is released.

The other graphical browser of note is iCab on the Mac—as of this writing, while its support of many other standards is quite impressive, the 2.0-alpha version still doesn’t seem to support Javascript or CSS1 or 2, though the official release due in August is supposed to. We shall wait and see.

Back to content

Makiko Itoh is a partner at PRODOK Engineering, a consulting, design and fix-it company based near Zurich, Switzerland.