Resources > Testing Sites

This gives miscellaneous information related to the testing of websites; much of this information is about site design, because many design issues affect testability. This page is organized into these sections:

• Avoiding Browser Differences
• Browser Oddities & Stupidities
• Automated Tools
• Test Suites
• Design Considerations

Note : this page offers suggestions which you will not welcome unless you focus on making pages which meet the needs of a site’s owner and users. If your priority is making cool, flashy sites which flaunt your design prowess, this is not for you.

Avoiding Browser Differences 

Testing is easier if — from the very start — you design in ways that reduce browser differences, or that make differences less important. Here are a few guidelines:

• Keep it Simple
• Design to the Standards
• Test to the Standards
• Use Only Well-Formed HTML
• Use CSS Exclusively for Layout
• Exclude Old Unused Browsers — Carefully
• Avoid Bleeding Edges
• Avoid Over-Precise Control of Layout
• Avoid Complex Font Sizing
• Avoid Overcrowding Pages
• Avoid Poorly Supported Aspects of Standards When Failure Would Impair Functionality
• Use Programming Languages Like Javascript Very Cautiously
• Avoid Browser Sniffing

Keep it Simple

Keep the design and code simple: strive to make it simply perfect.

Design to the Standards

Design to the standards, using a DOCTYPE and meta tag which make browsers honour standards more strictly, and validate your code using an HTML validator and a CSS validator.

For new designs, use HTML 4.01 Strict and CSS 2.1 (or maybe xHTML 1.0 Strict and CSS 2.1). For old sites you may use a Transitional HTML or xHTML standard until you are ready to update to a Strict standard. Note : using xHTML is contentious; some argue you should not use it, and you should ponder their advice.

Use emerging standards like HTML 5 and CSS 3 very carefully: use elements of these standards only if your sites will work without these HTML and CSS elements; and use elements of these standards only if they are implemented reliably by all browsers which support the standards.

Note : to learn about the benefits of designing to the standards, see Using Web Standards in your Web Pages.

Note : compliance with standards can have very subtle, unexpected consequences which can result in pages not working as expected even when there is nothing wrong with the code. For example some browsers which are highly standards compliant will ignore files which don’t have the proper MIME type, e.g. CSS files which aren’t of type text/css. Something like this can be very hard to debug, because the natural tendency is to believe that the fault is in the code, when the fault is actually in how the server is configured.

Caution : it is fairly common to have a page which works as expected in quirks mode, but not in strict mode, even when the code is valid. When this happens with a browser which is highly standards compliant, it is possible that the problem is due to a browser bug: but it is far more likely that the browser is behaving properly in strict mode, but that the browser does not behave as you expect because your understanding of some element of the standards is incorrect. You should use such problems as a learning opportunity: your objective should not only be to make the page work in strict mode as expected, but also to learn where you went wrong so that you are less likely to repeat your error in the future.

Test to the Standards

Test first with browsers which comply well with the standards. Once the design works with such browsers, test with lesser browsers. Problems are most likely with versions of Internet Explorer older than IE 8.

When tests reveal problems due to browser defects, it is usually possible to tweak the code to fix the problems, but still honour the standards. If you must use non-standard code to fix an IE problem, use conditional comments so that other browsers don’t see the deviant code.

Do not assume that there are no errors in a page that looks right: it is common to believe that, if a page looks right, it is right. First, some errors may not be obvious. Second, a browser that does not conform to the standards may wrongly produce the results you expect. And third, some browsers — most notably IE — try hard to recover from errors gracefully by guessing what the designer intended, which hides errors. Often the first sign that there is a problem with your code is that your page looks bad with a different browser, or when it is resized, or with a different font size.

Use Only Well-Formed HTML

Use only well-formed HTML, where tags nest properly, and no optional end tags are omitted: some legacy browsers can misbehave badly if the HTML is not well-formed. [more...] Code checkers may warn about deviant code. [more...] Note that xHTML must be well-formed, so a validator alone will suffice to find badly formed xHTML.

Use CSS Exclusively for Layout

Use only CSS for layout; for consistency, put the CSS in files which all pages share.

Caution : the CSS 2.1 specification does not say how marker positions or indent sizes for the <li> tag should be controlled. Different browsers and different versions of a browser may control them in different ways, so setting a certain margin and padding for a list may produce good results for one browser and awful results for another: you may need different CSS for different browsers — and perhaps for different versions of a browser — and you must test very carefully with your full test suite.

Exclude Old Unused Browsers — Carefully

Before starting, decide which browsers need not be supported. Extinct browsers like as IE 4 and Netscape 4 clearly do not have to be supported, but fading browsers might have to be. Different sites attract different types of users, and some sites attract more people who use old browsers.

At the time this was written (Nov 2009) dealing with IE 5 was a big problem, because its support of standards is abysmal compared to more common browsers, but some sites still attracted many IE 5 users. This site, for example, had 2.1% IE 5 users in Mar 2009. If you are certain that you can safely exclude IE 5, you will save a lot of time.

If an old browser must be supported, you must accomodate its defects and limitations, you must do more extensive testing, and you may have to eschew features supported by more capable browsers if the results with the older browser would be unacceptable.

Avoid Bleeding Edges

Avoid being tempted to use elements of standards which are very new and supported by few browsers. Even browsers which do support such features may not do so completely or reliably. This especially applies to elements of standards for which the prescribed behaviour is complex. It is safer to use elements of standards which are simpler or which have been supported for quite some time, since there has been time to find and fix the bugs.

A contentious issue is when to use elements of emerging, unreleased standards, especially elements which enjoy a fair amount of browser support. Examples are the HTML 5 <canvas> tag and the CSS 3 opacity property. New standards likely will not be fully supported by most browsers for a long time. But this has also been true of existing standards: e.g., 10 years after its release CSS 2 was not fully supported by any browser, and never will be. This author’s view is that well-established elements of proposed standards may be treated much like elements of official standards: if using such an element makes the site more effective, but the site can still be effective without support of that element, then it is okay to use it, especially if the element is simple and well-defined. Nonetheless, using anything which is not universally supported complicates testing, and using anything which is not in a released standard complicates validation, so there must be a compelling reason for using elements of emerging standards.

Avoid Over-Precise Control of Layout

Avoid over-precise control of layout: otherwise you may create fragile pages that break when browsers don’t do layout as you expect, and you will waste time fighting how different browsers do layout, and how user preferences affect layout.

It is a common mistake to believe that layout can be precisely controlled. Browsers may do layout incorrectly because they are not standards-compliant. Browsers may do layout correctly but unexpectedly because (1) some elements of standards are optional, ambiguous, or unspecified, (2) layout is affected by user settings, PC configuration, and display technologies, or (3) you wrongly understand how code should affect layout.

It is also a common mistake to believe that layout should be precisely controlled. Many designers — especially fledgling designers — try to treat a web page like a sheet of paper, with content to be placed in precise, pixel-perfect positions, with fonts of precise, pixel-perfect sizes. Such a view is wrong: a web page is an elastic medium which can adapt — and should adapt — to users with a wide range of devices and abilities.

Sadly, GUI authoring tools encourage precise layout. When told about problems, designers using these tools are often bewildered, denying that problems could possibly occur, or having no idea how to prevent them.

Here are some common problems resulting from attempts to control layout too precisely:

• Blocks may overlap if the user‘s font size is larger than the designer expected. E.g. here is overlapping text in a page made by a professional designer using Dreamweaver:

  

  In another example, from a well-known company’s site, the menu overlaps and distorts a search box:

  

  Note : this problem is more common when designing for IE with font sizes in absolute units, e.g. in pixels. Designers may wrongly assume that users cannot change the sizes of such fonts, because IE makes it somewhat difficult to do so. Designers may therefore wrongly assume that such text will always fit into blocks of predictable sizes. In fact, however, users can even resize fonts specified in absolute units — albeit more easily with some browsers — so sizes of blocks containing text are not truly knowable, and overlaps can occur if blocks are placed at absolute locations.

• Another problem is unwanted gaps. E.g. here is the header of a page made by another professional designer using DreamWeaver: a larger than expected font below the header’s sliced image results in a large horizontal gap and a 1 pixel vertical offset in the header’s slices:

  

  Another example of this problem, this time in a site made by a designer using NetObjects Fusion, is this one, where vertical gaps appear between rows of a sliced image because text to the right of the slices was larger than the designer expected:

  

• A third problem arises when the designer not only places page elements at pixel-perfect locations, but also trys to fit the content within fixed-size blocks: if the user’s font size is larger than expected, the content may be too large to fit within the blocks, and the content may be cropped. Here is an example where this occurred on the CNN home page:

  

• A fourth problem appears when the designer tries to control layout precisely in order to cram as much as possible into a small space. The page can be so crowded that people have a very hard time finding what they are looking for, and reading what they have found. Also, the page can be so crowded that it cannot be made accessible to the disabled.

  In many cases it is better to break up the page into multiple pages joined by links. For example, one page might list what information is available — as a list of headlines with teasers — with links to pages containing the actual information. Such pages can be smaller and more open, with more whitespace, which makes them faster to load and easier to use. Such pages are easier to test, because an open layout is less likely to break than a layout which is very compact.

• A fifth problem appears when the designer uses positioning techniques which have browser dependant results: this can happen when the site is made for a browser which fails to conform to the standards, but it can also happen when the standards allow different browsers to produce different results. Here is an example created using Microsoft’s Visual studio .NET, where a bullet and part of the text are missing in the first column if the user does not have Internet Explorer:

  

• A sixth problem is that pages may look bad on devices with small displays, e.g. cellphones.

• Other problems include such things as: pages requiring horizontal scrolling (because the designers assumed a specific window size wider than some users have); pages with large whitespaces on the right side of the browser window, or on the left and right sides (because the designers assumed a specific window size much less than some users have); navigational buttons too small to be read by some users (because the designers made the buttons from images).

Avoid Complex Font Sizing

Avoid complex font sizing: setting sizes in complex ways, or setting a myriad of sizes, can cause unwanted and nonobvious differences in how browsers size fonts, especially with older versions of Internet Explorer. Here are a few guidelines:

• First, decide the size of normal body text: all else depends on this. The size should honour the user’s preferred size. There are three primary options:

  • Use the user’s preferred size. This should be the ideal size, except for one catch: websites have traditionally set the size smaller than the user’s preferred size, so many users have compensated for this by increasing their preferred size in order to get the size they truly want. This means, however, that text becomes too large for sites which don’t set a smaller size.

  • Use a smaller size. This should be the right size for the users who have set their preferred font size larger than what they truly want: but then text will be too small for everyone else.

  • Use the user’s preferred size, but let the user change it, for example by letting the user switch to a smaller size. Sites which adopt this approach often offer an icon to enlarge or shrink the font size: if the size is saved in a cookie, the user’s choice can be honoured throughout that site, which is a neat solution to the problem — but only if JavaScript and cookies are enabled.

  Whichever size you pick will annoy many users, who may be forced to change their font size in order to make your site usable. Right now this author has no recommendation: this site, for example, once used the second option; now it uses the first; neither has proven a happy choice.

• Second, decide the sizes of the headers. A factor to consider here is that many browsers surprisingly set <h5> and <h6> headers smaller that the user’s preferred size. A solution is to make both <h5> and <h6> the same size as body text, but styled to make them distinct: for example, the <h6> header could be made italic, or a lighter colour.

  Larger headers should be sized proportionally. One problem here is that, if their sizes are made very distinct, the largest headers may be too large. A solution is to make their sizes more alike, and to use styling to make them distinct: e.g. this site puts a horizontal rule above <h3> headers, hence the sizes of <h2> and <h3> headers — or <h3> and <h4> headers — can be made more alike.

• Third, decide the sizes of smaller body text, e.g. for menus, footnotes, and superscripts. It is best to pick only one smaller size: picking several smaller sizes may result in the smallest text being unreadable, and other sizes being indistinguishable due to pixel rounding. Remember, too, that some browsers let the user set a lower limit to the font size: if you try to set a smaller size, the lower limit will be used instead.

• Fourth, don’t set smaller sizes assuming that the font is Verdana — or some other font with a large ex-height — because the text may be unreadably small if the user does not have that font.

• Finally, decide the method you will use to set the sizes. This is complicated by browser differences, especially in older versions of Internet Explorer. This issue is discussed in Resources > Fluid Design and Font Sizes.

Avoid Overcrowding Pages

Avoid overcrowding pages: use whitespace wisely. Making crowded pages makes it harder for users to find information, and increases the likelihood that the layout will fall apart if the browser behaves a little differently than expected, or if the user needs a larger font than expected, or if the user has a device with a small screen, such as a web-enabled cellphone. Making crowded pages also makes it more likely that the tester will fail to notice small or subtle problems.

One especially nasty consequence of overcrowding pages is that it creates a tendency to use unreadably tiny fonts to cram more text into tiny spaces. Here is an example:

The text here is 10 pixels high, 6 pixels smaller than what this author prefers for optimum readability. The tiny text will create two problems: first, it will be harder for people to read the headlines, and therefore recognize news items in which they might be interested; second, it will make it more likely that people will leave the site and go elsewhere, to a site which is easier to read.

Avoid Poorly Supported Aspects of Standards When Failure Would Impair Functionality

Avoid using poorly supported aspects of standards when failure would impair functionality: e.g. avoid CSS fixed positioning, which is not supported by IE6 and its progenitors.

Because many people continue to use old, less capable browsers, even when much better versions are available, you may have to avoid using some poorly supported elements of standards for many years, until so few people use the old browsers that you can reasonably exclude these people from your websites.

If you must use something that is poorly supported, use a proven workaround that works with all browsers. E.g. if you need getElementById(), which old versions of IE do not support, cloak it in this equivalent function, which uses IE’s document.all[] when getElementById() is missing:

function getElement ( id )
{
var element = null;
if ( document.getElementById )
  element = document.getElementById( id );
else if ( document.all )
  element = document.all[id];
return( element );
}

Another example of a proven workaround is to hide HTML or CSS that must be seen only by specific browsers by using @import restrictions or IE conditional comments. E.g. this HTML links to ie50.css only if the browser is IE 5.0x, enabling one to create CSS that copes specifically with IE 5.0x incompatibilities:

<!--[if lt IE 5.5000]>
  <link rel="stylesheet" type="text/css" href="ie50.css">
<![endif]-->

Use Programming Languages Like Javascript Very Cautiously

Use programming languages like JavaScript very cautiously: develop software only when needed; make maximum use of standard, proven components and techniques; and understand the standard components so that you can adapt them to meet your evolving needs.

Creating software disproportionately increases development costs, because it is harder to make good software — and to maintain it — than it is to make and maintain good HTML and CSS.

Creating any software for a site adds an additional level of complexity, especially when “pushing the envelope”. In addition, using a client-side language like JavaScript increases the risk of encountering browser differences. JavaScript differences include such things as features missing (especially in older versions), features added (especially proprietary features), and features broken (e.g. when a browser fails to correctly adhere to the specifications). A good JavaScript reference manual is essential, but even a good manual cannot cover all possible problems.

Using software components supplied by others can be useful, but if they become outdated and you cannot adapt them to changing needs, they become a liability .

One especially troublesome issue is the use of document.write to generate HTML or CSS “on the fly”, as the browser is parsing the HTML or CSS: the code generated may not be inserted where you might expect, and may be inserted at different places by different browsers; or the code generated may be inserted where you expect, but a browser’s parser may get confused and fail at some later point. Often it is safer to wait till the page is displayed, and then use the innerHTML method to dynamically change the page.

Avoid Browser Sniffing

Avoid browser sniffing, since this is not entirely reliable.

For more information about browser sniffing and the alternatives, see Resources > Browser Sniffing.

Browser Oddities & Stupidities 

Testing is made more difficult by a number of contentious things which browser makers have done:

• All Browsers
• Firefox Oddities & Stupidities
• Internet Explorer Oddities & Stupidities

The information below would be much, much longer if horribly broken browsers like Netscape 4 were still being used. Thank goodness that old browsers do die, eventually.

All Browsers 

Browser Bugs

Browsers, like most other software, have bugs, and many bugs affect how pages are rendered, often in obscure situations. Older browsers have more bugs, and more serious bugs, so bugs are a bigger problem for users who do not (or can not) keep their browsers up to date.

This author found that, in Jan 2008, the biggest problems are IE older than IE 7: other browsers, such as Firefox and Opera, create fewer problems because their users tend to keep up to date; IE is a problem, not only because many users refuse to update (e.g. many IE5 users refuse to update to IE6), but also because some users can’t update (e.g. all IE5 users, and many IE6 users, can’t update to IE7 or IE8, because IE7 and IE8 are not available for versions of Windows older than XP SP2).

There are workarounds for many bugs — e.g. the notorious IE peekaboo bug — and there is much information on the Internet about these bugs and their workarounds. Experience and experiment are required to solve each bug.

Browser bugs complicate testing, especially when bugs are triggered by conditions which might not appear during routine testing. Internet Explorer should be tested more brutally.

Caching Issues

Caches are used by browsers to improve performance, but unfortunately browsers may display pages using cached files even when updated files exist. As a result, when you update the file(s) from which a page is built, then reload the page, the browser may display the older page instead of the updated page, or worse, it may display a page by combining some files which are old, and some which are updated.

To make things worse, caching can also take place at the server or at points between the PC and the server.

This can complicate testing because it may not be obvious when loading a page that the browser has used old files: a problem can either be hidden or created by the use of old files.

There are ways to minimize this problem, for example by configuring the browser to use its cache less, or by using a command which supposedly makes the browser refresh a page using the latest versions of the files, but the bottom line is that this problem cannot be eliminated. For more about this, see the Wikipedia article Bypass your cache.

DOCTYPES

Most browsers use the DOCTYPE to decide how strictly to apply standards. Using the DOCTYPE for this purpose is not part of any official standard, but it has proven useful for making it possible to apply standards properly without breaking legacy pages which were designed when today’s standards either did not exist or were very new. As discussed elsewhere, there are two or three DOCTYPE modes: quirks mode, which asks the browser to misbehave like legacy browsers; standards mode, which asks the browser to comply with the standards; and (except for Internet Explorer) almost-standards mode, which differs from standards mode only in how it calculates the heights of images within blocks.

One facet of using DOCTYPEs for this purpose is that, because there is no standard, some DOCTYPEs trigger different modes in different browsers. To help make browsers behave alike, only DOCTYPEs which trigger standards mode in all browsers should be used, so only a few are recommended DOCTYPEs.

Another aspect of using DOCTYPEs for this purpose is that it has encouraged lazy designers to continue to make broken sites: designers omit the DOCTYPE or pick a DOCTYPE which triggers yesteryear’s quirky browser behaviours, focus on making websites which appear to work with their version of Internet Explorer, then complain in bewilderment when other browsers do not render their broken code the same way that their version of Internet Explorer does. The introduction of a meta tag by Microsoft in IE8 (and, presumably, later versions of IE) to make IE work like an older version makes it even easier for lazy designers to make broken sites.

Using a DOCTYPE which triggers standards mode will make it more likely that browsers will act alike: there may still be differences, but there will be fewer than with quirks mode. Using such a DOCTYPE is therefore an important part of making it easier to test sites.

HTML 5 may change this: the official position of its creators is that the DOCTYPE has no purpose, so HTML 5 will have the unadorned DOCTYPE <!DOCTYPE html>: but there is no provision in this for an HTML 5 page which retains some elements of older standards for backwards compatibility. We live in interesting times.

Header Font Sizes

Browsers often perversely make the sizes of <h5> and <h6> headers smaller than the size of normal body text. If you use such headers, therefore, you should consider setting your header font sizes yourself, e.g. using this CSS:

h1 { font-size:1.75em; }
h2 { font-size:1.52em; }
h3 { font-size:1.32em; }
h4 { font-size:1.15em; }
h5 { font-size:1.00em; }
h6 { font-size:1.00em; font-style:italic; }

Non-Standard CSS

Most browsers support some CSS which is not part of today’s official standards. In some cases the CSS is part of a draft standard; in some cases the CSS has been proposed — but not accepted — as an addition to a draft; and in some cases the CSS is inherently peculiar to a single browser.

Examples of CSS in an emerging standard are the opacity and text-shadow properties, which are defined in the draft CSS 3 standard. Use of such CSS clearly complicates testing, since browser support is uneven: but, on the other hand, this is just as true of unevenly supported features of CSS 2; well defined CSS 3, therefore, cannot be excluded just for this reason. Use of such CSS may be justified if there is enough browser support to make it worth the effort, and if the absence of support by other browsers is harmless, or can be made harmless.

An example of CSS which was a proposed standard, but which was not accepted, are the properties which Internet Explorer and some other browsers recognize for styling scrollbars. Use of such CSS may, perhaps, be justified — styling scrollbars is particularily contentious — but again only if there is enough browser support to make it worthwhile, and only if the absence of support by other browsers is harmless, or can be made harmless.

An example of CSS which is peculiar to a single browser is Internet Explorer’s alpha transparency filter. Though it is only supported by Internet Explorer (and not by IE 8), it is the only way to make older versions of Internet Explorer support alpha transparency in PNG images. Since all other browsers support alpha transparency in PNG images properly, without a filter, using this particular proprietary CSS can be justified to ensure that pages work the same for all browsers. Using other proprietary CSS, however, is more contentious, and harder to justify.

In any case, use of such CSS complicates testing, and this must be a factor in deciding whether to use such CSS.

Non-Standard HTML

Most browsers support some HTML which is not part of today’s official standards. In some cases the HTML is part of a draft standard; in some cases the HTML is archaic HTML created for browsers which today are extinct; and in some cases the HTML is peculiar to a single browser.

An example of HTML in an emerging standard is the <canvas> tag, which is defined in the draft HTML 5 standard. Use of such HTML clearly complicates testing, since browser support is very uneven. Use of such HTML may be justified if there is enough browser support to make it worth the effort, but only if the absence of support by other browsers is harmless, or can be made harmless. It is very important to use such HTML only if it helps make a site more effective, and only if the site remains effective even when the HTML is not supported.

It is easier to use non-standard CSS than non-standard HTML, because much CSS in emerging standards can be used in such a way that all browsers show the content even if they make the content appear differently.

Two examples of archaic HTML are the <blink> and <marquee> tags. The first was a Netscape invention, the second a Microsoft invention, and neither is in today’s standards.

Another example of archaic HTML is the background attribute of the <table> tag: this attribute is not in the standards, but its use was justifiable years ago when old browsers supported this attribute but did not support equivalent CSS. There is no justification for using such HTML today.

Examples of HTML which are peculiar to a particular browser include the HTML which Microsoft invented to enable documents to be converted from Word format to HTML format, and back, without loss of formatting information, e.g. <o:SmartTagType>. Such HTML should never be used in web pages.

The bottom line is that you should not use non-standard HTML, except possibly HTML which is well-defined in an emerging specification: and if you use such HTML, you must make sure that the site remains effective without it, and you must accept that this complicates testing.

Non-Standard JavaScript (and DOMs)

Since JavaScript and the DOM are inextricably intertwined, this discusses both together. For brevity, JavaScript will be used to refer to both.

Most browsers support some JavaScript which is not part of today’s official standards. In some cases the JavaScript is part of a draft standard, or has been proposed for such a standard; in some cases the JavaScript is archaic, created for browsers which are extinct, or nearly extinct; and in some cases the JavaScript is peculiar to one browser.

An example of JavaScript in an emerging standard are the generators and iterators supported by the Gecko 1.8.1 browser engine. It is difficult to justify using such features: cross-browser support is poor, acceptance in new standards is far from certain, and some browser makers have objected very strongly to these features, so support by their future browsers is especially uncertain. Use of such JavaScript may be justified, but only if the benefit is very great, and only if there is a viable alternative for other browsers: an example might be a new feature which makes critical code much faster, where more conventional code can be created for browsers which do not support the new feature. Such software is inevitably more complex, and is therefore more prone to software bugs, and more difficult to test.

An example of archaic JavaScript is Internet Explorer’s document.all[] array, used to get the element associated with an HTML ID. The document.getElementById() method should be used instead, but Internet Explorer 5.0x for Windows, which is still in common use, does not support it: for this reason it is necessary to use object detection to decide whichever technique to use. It is best to encapsulate such archaic JavaScript in a function which uses the appropriate technique, for example:

function getElement ( id )
{
var element = null;
if ( document.getElementById )
  element = document.getElementById( id );
else if ( document.all )
  element = document.all[id];
return( element );
}

Encapsulating such differences in a standard, tested function keeps the software simple, and makes testing no more complex.

An example of JavaScript which is peculiar to one browser, is JavaScript for Internet Explorer to detect plugins. An array navigator.plugins[] should have details about installed plugins, but Internet Explorer stupidly does not support it. Code unique to Internet Explorer must therefore be used. Code to get information about plugins should be encapsulated in a function which uses the appropriate technique, though this is harder because different code is needed for each Internet Explorer plugin.

The bottom line is that you should not use non-standard JavaScript, except when it is extremely important to do so, and when the JavaScript differences are encapsulated within standard functions which make it unnecessary for other code to care about the differences. Creating a new standard function will complicate testing, but using a proven standard function should not.

Firefox Oddities & Stupidities 

Automatic Image Resizing

Like many browsers, Firefox can automatically resize (shrink) images which are too big to fit within the browser window. This can be nice for the user, as it enables users to view large images without scrolling, but it can make it harder to test sites, since the resizing can obscure problems. It is therefore vital to disable resizing during testing. This is easy to do with many browsers, including Internet Explorer, Mozilla, SeaMonkey, and Firefox 1.5: but it is harder to do this with Firefox 2 because, in an act of appalling stupidity, the Firefox makers removed the option from the Preferences in Firefox 2: resizing can only be disabled using Firefox’s arcane about:config page.

To disable resizing with Firefox 2 or 3, it is necessary to set the following about:config property to false:

browser.enable_automatic_image_resizing

CSS Default Fonts

As discussed elsewhere, CSS recognizes five generic fonts: serif, sans-serif, cursive, fantasy, and monospace. To test a page which is styled using these fonts, it is necessary to determine which font is used, and to do this it can be helpful to be able to select generic fonts which can be easily distinguished. Firefox’s progenitor, Mozilla, enables one to select all the generic fonts, but the Firefox makers foolishly chose to remove this feature. (The Firefox makers appear to believe that taking features away from users makes Firefox easier to use.) This can complicate testing. Designers who make pages using all five generic fonts should consider using SeaMonkey instead of Firefox for testing, since SeaMonkey still allows all five generic fonts to be selected. Alternatively, designers can avoid using the cursive and fantasy generic fonts.

CSS Font Size

Firefox 3 changed how Firefox calculates font sizes, in such a way that text which should be of different sizes is rendered in the same size. For example, the text size resulting from font-size:small can be identical to font-size:x-small. Whether this happens depends on the user’s default font size and on other factors which are not clear. This results in pages which look disconcertently different from what they should be.

You can check this effect by examining the following line:

medium small x-small xx-small

Internet Explorer Oddities & Stupidities 

Colours

Internet Explorer distorts colours. Usually the differences are not obvious, but there are exceptions: for example, when the edges of an image have the same colour as the image’s background, so that the image should blend in with the background, Internet Explorer may distort the colours, resulting in a noticable colour change around the image which prevents the image from blending in.

For example, here are screen captures of the same image, with a solid background chosen to make the image blend in, as it appears with Firefox 3 and Internet Explorer 7. Firefox displays the image correctly; Internet Explorer distorts the colours.

With 16-bit (64K colour) monitors, colour distortion may be unavoidable and is found in all browsers: but with 24-bit (16M colour) monitors, there is no justification for colour distortion, but Internet Explorer — and only Internet Explorer — nonetheless may distort the colours.

CSS Box Model

With the CSS box model, the width of a box is the width of the contents of the box, excluding padding, borders, and margins. Internet Explorer wrongly makes the width include the padding, borders, and margins, in IE 5, and in quirks mode in IE 6-8: in standards mode, IE 6-8 handle the width correctly.

If standards mode is used, there are testing problems, but only with IE5. To avoid problems with IE5, simply design the page so that the width is not critical, i.e. so that the page works well enough even with the wrong box model.

CSS Default Fonts

As discussed elsewhere, CSS recognizes five generic fonts: serif, sans-serif, cursive, fantasy, and monospace. To test a page which is styled using these fonts, it is necessary to determine which font is used, and to do this it can be helpful to be able to select generic fonts which can be easily distinguished. Unfortunately, IE picks the five fonts, and does not allow the user to select them, so if IE picks fonts which cannot be easily distinguished, people testing pages can do nothing about it.

CSS Errors

When Internet Explorer encounters a CSS coding error, it may guess what the designer intended and render pages accordingingly, whereas the CSS standards say that browsers should ignore such errors. The result is that Internet Explorer obscures errors, making testing harder.

An example is height:20: this is an error because no units are specified; units are mandatory unless the value is zero. Internet Explorer commonly assumes that the designer meant height:20px, and renders pages accordingly: such errors are common, probably because dimensions are not required in HTML, where pixels are the standard unit, so sloppy designers can easily err when they create similar CSS. An amazing number of pages on the Internet have such errors.

The best way to prevent this problem is to only test sites which have been validated, hence have no CSS errors.

CSS for IE 5.01

Some sites still attract a significant number of IE 5.01 users, and these sites present a special challenge due to 5.01’s abysmal CSS support: there is much that 5.01 does not do; and much that it does do, but wrongly. Users should upgrade, at least to IE 6.0, but many users will not, or can not.

Some major 5.01 CSS problems are: it has a broken box model; it does not support many CSS properties; and it supports inheritance very badly.

Sites which support 5.01 users should be tested more thoroughly, and will likely need a special stylesheet, imported using conditional comments, to override the CSS used by more capable browsers.

DOCTYPEs

As discussed elsewhere, browser makers have chosen to use the DOCTYPE to decide how strictly to honour the standards. This use of DOCTYPEs is not prescribed in the standards: it is just a common way of enabling browsers to better honour the standards without breaking legacy sites.

A problem with IE is that versions older than IE7 require that the DOCTYPE appear on the very first line of an HTML file: if it is not on the first line, IE will render pages in quirks mode.

To avoid this problem, it is advisable to always put the DOCTYPE on the first line.

Font Sizes

When the designer specifies a font size in absolute units, e.g. pixels, Internet Explorer makes it harder for a user to make it use another size. Many designers appear to assume that it is not just hard, but impossible, and therefore design a site assuming that the font size will always be exactly what they specify. However, it is possible to override the designer’s font size in Internet Explorer, and it is very easy to do so with many other browsers. The designer’s false assumption can, therefore, result in pages which look awful when the user overrides the size, e.g. to enlarge the text to make it more readable.

Note : the user can tell Internet Explorer to honour their preferred font size, ignoring the size set by the designer, using the command Tools, Internet Options, General, Accessibility, Check “Ignore Font Sizes Specified on Web Pages”. This is even easier with other browsers: with Firefox and Safari, for example, the user can simply do Ctrl + or Ctrl - to increase or decrease the font size. In this author’s experience, few people know about the Internet Explorer option, so it is easy for both designers and users to believe that it is not possible to override the font size.

The best way to deal with this is not to specify font sizes in absolute units, but instead to specify the sizes in ways which result in text growing or shrinking as the user’s preferred font size grows or shrinks. This is an element of “fluid design”. There are four ways of doing this, which are discussed in Resources > Fluid Design and Font Sizes.

Note : this author recommends that only two font sizes be used for most body text, one size for normal body text, and a smaller size for footnotes and possibly for sidebars. Using more than two sizes for body text makes it harder to pick sizes which are readable, but clearly distinguishable, and may also confuse users, who could wonder what the significance of the different sizes is.

Something that often goes along with setting font sizes in absolute units, is setting positions of content at absolute positions: a designer who wrongly assumes that browsers will honour fixed font sizes will also often wrongly assume how much space the text will occupy; and such a designer may therefore position other blocks of content at specific, absolute positions, which often results in content overlapping or being cropped when the browser does not honour fixed font sizes. It is therefore important not only not to specify fixed font sizes, but also not to specify absolute positions for content. This is another aspect of fluid design.

HTML Errors

When Internet Explorer encounters an HTML coding error, it guesses what the designer wants to happen, and renders the page accordingly. This can be good for users, because it makes pages usable which might otherwise not be usable, but this can make it harder to test sites, because it can obscure errors, and because other browsers likely will not behave the same.

The best way to prevent this problem is to only test sites which have been validated, hence have no HTML errors.

JavaScript Errors

When Internet Explorer encounters a JavaScript error, it offers information about the error, but the information is often too sparse to be useful: it reports only one error at a time, and although it reports the number of the line where the error was encountered, the number can be wrong, and the file where the error was encountered is not named.

It is therefore better to test first with browsers which provide more information about JavaScript errors — e.g. Firefox or Opera — and to test with Internet Explorer only when these browsers report no errors: this leaves only any errors arising from differences in Internet Explorer’s implementation of JavaScript.

Mark of the Web

Internet Explorer has complex security options which give users a lot of control about what IE will allow, on a site by site basis. One aspect to this is that the security mode can depend on whether a site is local, on the tester’s PC, or remote, on the web. This can result in sites behaving differently when tested locally than when tested remotely.

To circumvent this problem, Microsoft supports a MOTW (a Mark of the Web) comment, which can be added to web pages to make IE run a local site as if it were remote. Designers who want to ensure that sites can be properly tested locally should add the MOTW comment to all pages of sites which are affected by IE’s security options.

Running Multiple Versions

Unlike most browsers, Internet Explorer for Windows stupidly allows only one version of Internet Explorer to be installed on a PC. This is because Microsoft perversely and unnecessarily chose to integrate Internet Explorer with the operating system. There are ways to install more than one version of Internet Explorer, but testing with multiple versions is not anywhere as easy as testing with multiple versions of other browsers.

Table Widths

With IE, specifying a <table> width of 100% will typically make the table extend beyond the right margin. To prevent this, designers should set table widths using CSS, and should use a technique like conditional comments to make the width 98% for IE.

XHTML

Internet Explorer 7 and its predecessors do not implement xHTML: they treat xHTML as if it were HTML.

There are two approaches to dealing with this. One is to always use HTML, never xHTML. The other approach is to use xHTML, but to follow the recommendations in the xHTML specifications to ensure that legacy browsers will render xHTML appropriately. Both approaches have their merits. This author prefers the latter approach, but recognizes that others do not agree.

Automated Tools 

Testing will be easier and quicker if you use automated tools that can find errors in your code. For example:

• Validators : HTML validators and CSS validators report syntax errors, i.e. violations of a language’s rules. Validators may also issue warnings, e.g. about dubious elements in the code.

  Using a validator is a fast and simple way to identify the most blatant errors. Because different browsers may handle errors differently, fix all syntax errors and critical warnings before manual testing.

  Using a validator and studying its error messages will also help you learn more about HTML and CSS, and so enable you to improve the quality of your work.

  Note : some authoring programs like FrontPage create invalid code; avoid using such programs.

• Code Checkers : code checkers report errors and warnings about a page or site, e.g. missing end tags, nesting errors, broken links, wrongly sized images, or accessibility issues. A code checker might report some of the same errors that a validator would report, but a code checker will go beyond this to report what appear to be errors in perfectly valid code. E.g. if you have an img tag with a src attribute naming an image file that does not exist, a validator will not report an error, because it does not violate the HTML syntax to refer to a missing image file; but a code checker should report an error, or at least a warning, because it is very likely that the code specifies either the wrong filename, or the correct filename of an image that has not yet been created.

  Many HTML code checkers and CSS code checkers are available. For example:

  Code checkers may issue warnings which you decide can be safely ignored. Deciding which warnings may be ignored can take time, so it is a good idea to change your code to eliminate even minor warnings so that new critical warnings are not hidden amongst old minor warnings, like needles in a haystack.

  One checker which can be useful is the free W3C mobileOK Checker, which warns of possible problems with sites for mobile devices. This checker, however, has some serious limitations: it is made for sites which are coded specifically for browsers in mobile devices; it is not friendly to sites made for more general audiences.

  For example: the checker complains if markup is used which is not XHTML Basic 1.1; it complains if CSS is used which is not CSS 1; it complains if images are not GIF or JPG; it does not handle the CSS @media attribute, so it complains about CSS in @media print blocks (which it should ignore, because such CSS is not for mobile devices), and does not recognize as special the CSS in @media handheld blocks (which is specifically for mobile devices).

  If, therefore, you make a site for all browsers, this checker is not for you, even if you specifically design the site to adapt well to mobile devices.

  The W3C is working on a specification for a CSS 2.1 subset for mobile devices; perhaps when this is released, the mobile site checker will be updated to accept more capable CSS.

  Using a validator and studying its error messages will also help you learn more about HTML and CSS, and so enable you to improve the quality of your work.

  Some code checkers let you do less stringent checks to minimize unwanted warnings: this may be useful after making minor changes, but you should do strict checks after major changes or before major testing.

• Error Consoles : these are browser windows which can dynamically report error and warnings detected while pages are loaded and used. Output in an error console likely indicates a coding error.

  You must load the error console:

  • Gecko-Based Browsers : many Gecko-based browsers support an Error Console (called the JavaScript Console in Mozilla and older versions of Firefox). To view it you must click Tools, Error Console (or Tools, JavaScript Console in Mozilla and older versions of FF). You may be able to increase the amount of information reported: e.g. with Firefox, setting the about:config item javascript.options.strict to true will make Firefox report more potential JavaScript problems.

  • Internet Explorer : IE has no error console. It can produce a popup that reports JavaScript errors, but the report is often of little use except to say that somewhere there is some kind of error: the details it gives are often wrong or misleading. For initial testing you should use a more capable browser.

  • Opera : Opera supports an Error Console, called the JavaScript Console in Opera 8 and earlier versions. To view it, click Tools, Advanced, Error Console (Tools, Advanced, JavaScript Console in Opera 8 and earlier). You can control attributes of the Error Console using a set of opera:config options. [more...]

  • Safari : Safari supports an error console called the JavaScript Console. To use it you must turn on logging of JavaScript errors and load the window. With Safari 1.3 and up you can output your own messages to the console. [more...]

  Error consoles are also useful in debugging, but will be discussed elsewhere.

• Sanity Checkers : these are tools which can be used to detect anomalies which might result from errors. Examples of sanity checkers are:

  • Dust-Me Selectors Extension : this is a free Firefox extension [more...], which can be used to identify CSS selectors which are not used. It could be that unused selectors can simply be deleted; it may be that they are needed, but not yet; or it may be that they should have been used, but weren’t, in which case the wrong selectors may have been used.

  • Web Developer Extension : this is a free Firefox extension [more...], which offers many functions useful to website designers, including functions which can be considered to be sanity checkers, such as these:

    • Disable JavaScript : this can be used to quickly check whether a page works as expected when JavaScript is disabled.

    • Display Alt Attributes : this displays the values of the alt text associated with images, making it easy to quickly check the text which would appear if the user disables images.

    • Outline Images Without Title Attributes : this can be used to identify images without title attributes.

    • View Generated Source : this is like View Source, except that it also includes dynamically generated HTML. This makes it possible to see if there are errors in dynamic HTML.

    There are many more useful functions, some useful for performing sanity checks, some useful for finding coding errors, and some useful for both.

Test Suites 

This discusses selection and installation of browser test suites.

Test Suite Selection 

The first thing you must do is decide which browsers you will test with. Deciding can be hard.

• Select Common Browsers
• Select Very Standards-Compliant Browsers
• Do Not Select Browsers Using the Same Browser Engine
• Consider Mobile Devices

Select Common Browsers 

You should clearly test with the browsers used by a significant number of your users. But what is significant? And how will you find out which browsers your visitors use?

When you decide what is significant, you decide how many people your site won’t serve, but you may also decide how effective your site will be. If you don’t serve old browsers, you will lose people who use those browsers. But to serve old browsers, you may have to eschew features offered by newer browsers, and this could make your site less effective.

When you try to find out which browsers your visitors use, you will naturally check the browser stats, but likely discover that the stats are unreliable or unavailable. For example, stats typically report how many use Gecko-based browsers, but not how many use which version of Gecko — because this information is not generally available — and knowing this would be very helpful because different versions have different capabilities: e.g. NN 7.0, with Gecko 1.0, is in many ways crippled when compared to NN 7.2, with Gecko 1.7.2.

A conservative strategy would be to deploy an initial site that supports very old browsers like Netscape 7.0, and then to study the access logs to decide whether the numbers justify supporting the browsers in site updates. With this strategy you may initially use features supported only by modern browsers, but only when this does not impair the site’s functionality. A side-effect of this strategy is that it compels you to make an initial site that is simpler, and this simplicity may result in a better site: needless complexity makes sites less effective.

Select Very Standards-Compliant Browsers 

It can also make sense to test with uncommon browsers which comply very well with standards: browsers are made more standards compliant as time goes on, so making your site work with today’s standards compliant browsers will help ensure your site will work well — or can be easily made to work well — with future versions of browsers which today are less compliant: e.g. if Opera does something properly which other browsers don’t, making your site work with Opera will help ensure that your site will continue to work properly when other browsers catch up to Opera.

It can also make sense to test with an uncommon, very standards compliant browser because this may reveal errors in your code which would not otherwise be obvious.

Do Not Select Browsers Using the Same Browser Engine 

You need not test with several browsers which use the same browser engine, because they will render pages alike: e.g. it is a waste of time to test with both Netscape 7.1 and Mozilla 1.4.1, because both use the same Gecko 1.4.1 browser engine. Exception : Google’s Chrome browser uses Safari’s AppleWebKit browser engine, but it has a different JavaScript interpreter, called V8: pages which use JavaScript, therefore, must be tested with both Safari and Chrome.

The common browser engines are listed on the page Resources > Engines.

Consider Mobile Devices 

More and more people are using mobile devices such as cellphones for web browsing. This presents major challenges for web design, which can be met in part by specifying CSS rules which are specific to such devices.

This author has made several existing sites — though not this site — mobile-friendly.

You should consider testing with a mobile browser, or with a browser than emulates a mobile browser. For example:

• Any browser supporting CSS 3 media queries may be used for sites which use media queries, simply by shrinking the browser window to the point where the media queries kick in. Most modern browsers support media queries. You can use:

  • Firefox to emulate mobile devices which use Firefox Mobile.
  • Opera to emulate mobile devices which use Opera Mini.
  • Safari to emulate mobile devices which use Apple’s WebKit.

  This is not a perfect solution for testing sites for compatibility with mobile devices, but it is nonetheless very useful.

• Apple iPhone Emulator (works with certain browsers only)

• Opera Mini 4.2 Emulator

• Opera Mini 5.0 Emulator

• Opera Mobile Emulator: (note that Opera Mobile honours CSS 3 media queries only when its “Mobile View” option is on)

Note also that makers of mobile phones often offer emulators, typically bundled with SDK’s, which may be used to test sites for their phones.

Test Suite Installation 

You likely want to install multiple test browsers on a single PC. This is possible, but there are problems, and each browser must be handled differently. The following gives information about installing and running these test browsers:

• Gecko-Based Browsers // Windows
• Opera // Windows
• Internet Explorer // Windows
• Safari // Windows
• Test Browsers // Other Operating Systems

Note : you can find many browsers for testing here, in the Browser News.

Note : to install multiple browsers, you need a moderate amount of hard disk space; to run multiple browsers at the same time, you need a large amount of RAM. Fortunately both are cheap.

Gecko-Based Browsers // Windows 

Installing multiple versions of Gecko browsers is simple. You can install as many versions as you like, but must install each in its own directory. You must also create a unique profile for each version. How to do this is nicely documented in mozillaZine.

Running Gecko browsers is more complex. You have to invoke the browser with an option specifying the profile. E.g.:

• Suppose you installed Firefox 1.5 in c:\test\gecko\firefox1.5\.

• Suppose you created a profile for it named FF1.5.

• You could then run Firefox 1.5 using this DOS command:

  c:\test\gecko\firefox1.5\firefox.exe -P FF1.5.

  It is easiest to do this in Windows by creating a .bat file with this command, and creating a shortcut to the .bat file. An example of such a file would be:

  c:\test\gecko\firefox1.5\firefox.exe -P FF1.5
EXIT

• The above only works, however, when you need to run only one version at a time. If you want to run more than one version at a time, you must first set an environment variable, MOZ_NO_REMOTE, e.g. in a .bat file:

  SET MOZ_NO_REMOTE=1
c:\test\gecko\firefox1.5\firefox.exe -P FF1.5
EXIT

Opera // Windows 

Installing multiple versions of Opera is simple. You can install as many versions as you like, but must install each in its own directory.

Running multiple versions of Opera is likewise simple: just run the version(s) you want.

Internet Explorer // Windows 

Installing multiple versions of Internet Explorer on one PC is complex, and there are several approaches:

• Using a Multi-Boot Facility

  With a multi-boot facility, install multiple copies of Windows on one PC, each copy with its own hard disk partition and its own version of IE.

  This is troublesome, because it is necessary to reboot in order to switch from one version of IE to another. It also is wasteful of hard disk space, which can be a problem unless the hard drive is very large. In addition, a software license is needed for each different version of Windows.

• Using Virtual PC

  With Microsoft’s Virtual PC, a free product, one can install virtual copies of Windows and certain other operating systems. E.g. on a PC with Windows XP Pro SP2 (and up), one could install a virtual copy of Windows 98 with IE 5, and a second virtual copy of Windows 98 with IE 5.5. The number of virtual copies is limited only by hard disk space; the number of virtual copies you can run at one time is limited only by the amount of RAM and the speed of the CPU.

  This is the technique recommended by Microsoft.

  To use virtual copies of Windows, however, you need a license for each virtual copy. E.g. if you want to test sites with IE5, you can use Virtual PC to install a virtual copy of Windows 2000, but you must have a license for Windows 2000. Exception : Microsoft issues free time-limited pre-activated Virtual PC images of Windows XP SP2 and Vista, each with IE6, IE7, or IE8, for those who wish to test multiple recent versions of IE on a single PC; Microsoft releases new time-limited versions periodically, so it is necessary to periodically remove the expired image and installer the newer image.

  Note : there is a Virtual PC newsgroup, microsoft.public.virtualpc.

• Using Microsoft’s Expression Web SuperPreview for Windows Internet Explorer

  This is a free program from Microsoft which helps see differences between IE 6 and IE 7 (if you have IE7 installed) or IE 8 (if you have IE 8 installed).

  It is available at the Microsoft Download Center.

  Caution : this author’s experience with this program was very, very bad; the installation program was seriously defective, displaying corrupt dialog boxes, and the installation process could not be aborted, even using Windows Task Manager.

• Using Hilbrand Edskes’ Internet Explorer Collection

  Using a technique discovered by Joe Maddalone, and refined by others, it is possible to install several versions of IE at once in the form of the Internet Explorer Collection.

  This technique is not reliable, however. This author has encountered three problems: (1) some versions of IE were broken and would not run; (2) on one occasion, use of the collection destabilized a PC, requiring the loss of two working days to recover from the damage; and (3) on one occasion, the collection’s IE 5.01 failed badly with a page’s JavaScript when that same page worked fine with IE 5.01 running under Virtual PC.

  Using this collection is much easier than using Virtual PC, but in this author’s experience the collection can’t be trusted.

Safari // Windows 

Aping Microsoft’s arrogance, Apple allows only one version of Safari to be installed in Windows. If you want to test multiple versions on a PC you must adopt a solution like those for Internet Explorer: use a multi-boot facility, or use a virtual copy of Windows with something like Microsoft’s Virtual PC.

Test Browsers // Other Operating Systems 

A product similar to Microsoft’s Virtual PC is VMware’s free VMware Player. It also lets you install virtual copies of operating systems, but it is better at supporting a non-Windows O/S. Especially useful is that you can install Virtual Appliances, which are easy to install pre-configured images of operating systems, e.g. an image of Linux with KDE and KDE’s Konqueror browser. A big problem, however, is that VMware will not let you download its Player unless you answer a large number of unnecessary and irrelevant questions.

There are several other approaches for testing with browsers when you don't have the right kind of PC or O/S:

• You can test pages with Safari remotely at iCapture.

• You can test pages with Safari remotely at safaritest.

Design Considerations 

You can adopt a design methodology that improves various aspects of site development, including testing:

Details:

• Keep it Simple 

  Keep it simple: simplicity means less to do; simplicity means less complexity in what you do; thoughtful simplicity means a better site that is easier to use ... and to test.

  This does not mean that a site must be starkly plain. A site should enable a pleasant browsing experience and project a positive image of the site’s owner, so the site must look good. Pages should simply not be overly ornate.

  Simplicity is the hallmark of great minds:

  • “Simplicity is the ultimate sophistication” — Leonardo da Vinci

  • “The cheapest, fastest, and most reliable components of a computer system are those that aren't there” — Graham Bell

  • “Complexity creates confusion, simplicity focus” — Edward de Bono

  • “Simplicity is prerequisite for reliability” — Edsger Wybe Dijkstra

  • “A complex system that works is invariably found to have evolved from a simple system that works” — John Gall

  • “The ability to simplify means to eliminate the unnecessary so that the necessary may speak” — Hans Hofmann

  • “Simplicity is the final achievement: after one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art” — Frederic Chopin

  • “Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away” — Antoine de Saint-Exupéry

  • “An honest tale speeds best being plainly told” — William Shakespeare

  Keeping things simple means using the available technologies wisely. E.g. when coding a page, the wisest choice is usually to use HTML or xHTML to specify structure, and to use CSS to specify appearance, with carefully chosen CSS classes for page elements which recur throughout a site: other choices may result in bloated, complex code that takes much more time to create and maintain.

  An often overlooked aspect of keeping things simple is to keep text simple. People want to find information quickly, and skim text to find what they want: they don’t want to wade through rivers of turgid text. Keep text simple, clear, and concise. This makes pages more usable, and text errors easier to find.

• Document Your Work 

  Document key information needed when developing or updating the site.

  For example, the documentation could list and briefly describe each file and JavaScript function: e.g., as I did for a baseball team’s site. The documentation may also include information that you might otherwise put elsewhere, e.g. a change log. The documentation should not duplicate what appears in other files, but since comments in source files (e.g. HTML, CSS, and JavaScript files) increase page load times, you should document such source files elsewhere.

  It is especially important to document software clearly and in detail — e.g. to specify what a method does, what its arguments and return value are, and how it responds to errors — and to do so during the design process, not later. I spent 27 years developing software before I began designing websites, and one thing I learned early on is that a major cause of bugs is poorly documented software. If you carefully document the behaviour of each software component before you implement it, you are much more likely to implement it correctly, and those using it will much more likely use it correctly.

  Software design is a science and art in which great attention to detail is essential. Poorly documented software means that some details will be unclear, likely will be misunderstood, and will often cause errors.

  Documentation must be up to date: errors are worse than useless. If you are not sure you can keep it up to date, you may be better off not creating the documentation in the first place. Note: the task of keeping documentation up to date is harder when the documentation is not in the same file as the things it documents: e.g. it can be easy to forget that changing a JavaScript file may affect documentation in a different file. You must exert self-discipline to ensure that documentation is up to date.

• Focus on the Details 

  Paying close attention to details is essential for efficient, effective design. It can sometimes be so easy to slap page elements together that fine details are overlooked, and it is mainly in the details that errors lurk: as the old saying goes, “The Devil is in the details”.

  Being able to focus on the details is a skill that must be practised consciously and assiduously over a long period of time, but your diligence will reward you with the ability to do better work in less time.

  A good way to learn is to learn from your mistakes. When you find an error, always ask yourself where you went wrong. Every failure is an opportunity to learn.

• Focus on What Browsers Do Well 

  Design for what browsers do well: trying to force browsers to do what they do badly invites needless problems.

  Heed the words of the poet, Henry Wadsworth Longfellow: “The talent of success is nothing more than doing what you can do well.”

  If you find yourself fighting the browsers, trying to force them to do reluctantly what you want, you likely are trying to make them do something they do not do well: stop fighting; find another approach that browsers do well.

  It is very common, alas, to try to make browsers do things they do not do well, e.g. because the designer is using features that are not well supported, or is more familiar with a medium with much different fortés, or could not resist unwise client demands. One common error is to try to control layout too precisely.

  It is also very common to fail to make browsers do things which they do especially well. For example, using CSS it is easy to tell browsers to make pages look different when printed than when displayed, e.g. by using fonts more suited for printing, by omitting menus which serve no purpose when printed, and by minimizing the use of colour to minimize the user’s print costs. Below is one page I made as it appears when displayed, and as it appears when printed:

  

• Focus on Effectiveness 

  Don’t do something just because it is possible: do it because it makes the site more effective, or because it enables you to do your work more effectively.

  Many technophiles are eager to use anything new or flashy, even when not needed for the task at hand: e.g. many designers create flash pages — entry pages with eye catching special effects having no functional purpose — adding to all phases of the development time, and annoying impatient visitors who simply want to use the site.

  A survey revealed that business professionals consider these to be important qualities of a great website:

  • It must offer what the visitor wants.
  • It must be up to date.
  • It must load quickly.
  • It must be easy to use.

  For an effective website, focus first on these qualities.

• Small is Beautiful 

  Practice making a site for mobile devices such as cellphones. Coping with the constraints of such devices will teach you lessons which will enable you to improve all your websites.

  For example, designing a site for small screens will forcibly remind you that users have a wide variety of screen sizes and resolutions, hence atune you to making sites which better serve a wider range of users. Also, designing a site for mobile devices should force you to reëvaluate what is truly necessary in a website: discarding what is not essential will make your sites simpler, more focused, more effective, and easier to test.

  One special insight which you may gain from making a site for mobile devices is that people on the go may have different needs than people seated in front of a PC: people on the go are more focused on what they can use right away, for what they are doing at the moment; you should find out what they will most want, make menus which make it easier to find it, and present it as clearly and compactly as possible. This author has found it useful, for example, to produce pages in which information which normally appears for users of desktop PCs — such as decorative images and supplemental text — will not appear to users of mobile devices, or at least will not appear on pages which mobile users would often access.

• Take One Step at a Time 

  When creating new pages, or changing existing pages, do your work one step at a time, with verifiable results at each step.

  This makes it easier to develop and test your work: if a new problem appears, you will know that it is caused by what you have just done, and therefore you only have to review the little bit of work you have done since your previous step. This process is called “incremental development”. Making massive changes before testing any of them makes testing — and debugging — a massive problem.

• Reduce, Reuse, Recycle 

  Reduce, Reuse, Recycle: this mantra helps reduce wasted time, in more ways that you might expect.

  • Reduce : as repeatedly said here, keep it simple and focus on effectiveness. You are designing the site for the user, not to show off your amazing technical virtuosity. Keeping it simple can result in a better site with simpler and smaller code, and this will of course be simpler to test.

    For example, don't use software and image rollovers for buttons: instead, make simpler buttons — preferably using styled text, not images — and either don't do rollovers, or do CSS rollovers. I once inherited a site with a menu generated by 230 lines of HTML, plus Java to control rollovers; I had to change the menu because it was impaired by the Eolas update, and I made a nicer menu with just 16 lines of HTML and 4 lines of CSS, with CSS rollovers. The old and new menus are pictured below:

      

    You might argue that what you want to do cannot be done without JavaScript or a plethora of image buttons, and this may be true, though CSS can do more than you might expect (as shown by the CSS styled text buttons depicted below): but is what you want needed? It may be that what you want is very pretty, but that something simpler will suffice; it may even be that something simpler will be better, e.g. because CSS styled text buttons like these are more accessible and load faster than image buttons.

    

    Note : some of these buttons have background images, and one uses an image (of a key) as content, but the buttons are still essentially text buttons: the set of buttons on a site all share the same background images, all styling and rollovers are done using CSS, and buttons automatically resize when the user changes their preferred font size; none of this can be done with pure image buttons.

  • Reuse : create common elements that are reused throughout the site. By creating a common element, you reduce the need to reïnvent and retest it when it is used elsewhere in your site.

    For example: use common blocks of code for elements such as headers and footers that appear on every page, perhaps using server side includes if your server lets you do this; create a template from one of the first pages you create, using the template when making later pages; create flexible CSS classes for common objects, e.g. sidebars. The sidebars on this page, for example, are styled using four CSS rules, plus one rule for the dropcap.

    Using common elements also helps make pages look more consistent.

  • Recycle : think of future sites when you design a site. Sometimes you can spend just a bit more time making a component or perfecting a technique that is a bit more general than is strictly required for one site, but which may be recycled in later sites. If you create just one or two for each site you make, you can quickly amass a library of proven components and techniques which you can recycle in other sites, saving much time in the long run.

    E.g. I made a browser sniffer for a site which I have used many times in other sites. It may do more than is needed in any given site — e.g. it identifies the Opera browser even when this does not matter for a given site — but the advantage of being able to use the same proven block of code over and over outweighs the overhead of a few redundant lines of code.

    Tip : when designing software, object-oriented programming often makes it easier to think about making components which can be repurposed.

• Location, Location, Location 

  Location, Location, Location: this mantra encourages consistency in organizing files to reduce confusion and errors.

  • Create a simple, consistent, fairly flat file structure for a small site’s files. E.g. I normally put all source files — the HTML, CSS, and JS files — in the home directory, image files in img/, and document files in doc/.

    One nasty factor to consider in picking pathnames is that Windows considers upper- and lowercase characters in pathnames to be the same, whereas most other O/S’s consider them to be different. E.g. Windows will deem BrowserNews/ and browsernews/ to be the same, but Linux will not. This means that, if the case of a character in a pathname is wrong, and both the development PC and the server run Windows, you will likely not notice the error during testing. This also means that if other sites link to your site — or if users set bookmarks to your site — URLs with characters in the wrong case may not be noticed. But if the site is later moved to a non-Windows server, the errors will become important, and the URLs will fail. You should therefore think twice before picking pathnames with mixed case characters.

    Note that this issue does not affect domain names: upper- and lowercase characters in a URL’s domain name are defined to be the same, no matter the O/S. E.g. www.BrowserNews.com is always the same as www.browsernews.com.

    A simple, consistent, flat file structure makes it easier to locate files. It can also help reduce coding errors: e.g. if you put all document files in doc/, then you know that any document pathname will be doc/*.*. (This may sound trivial, but I have often seen sites where images or documents did not appear simply because the designer had specified the wrong pathnames.)

    I go one step further and use a simple, consistent scheme to name files. E.g. all images that are buttons have pathnames beginning with img/but_, images of icons have pathnames beginning with img/ico_, and images of maps have pathnames beginning with img/map_. (Again this may sound trivial, but it helps to organize and identify the files, and to reduce coding errors: e.g. you won't think that img/but_home.png is anything other than the image of a button.)

    You may prefer a different convention. That’s fine: the important thing is that you be consistent with whatever convention you adopt.

  • Also, be consistent in the internal organization of a file.

    For example, I often organize a CSS file in four sections:

    • Simple rules that apply to the whole site, e.g. a rule for styling a normal link.

    • Sets of rules that apply to common elements on the site, e.g. rules for styling a sidebar.

    • Sets of rules that apply only to specific pages, e.g. rules for styling the sitemap on a Site Map page.

    • Sets of rules for printing, e.g. to specify a simpler monochrome look when printing pages.

    Organizing CSS files in this way can make it easier to find a relevant rule and can reduce the likelihood that a rule will fail because of a related rule that is not nearby in the file.

• Don’t Reïnvent the Wheel 

  There are many websites out there, some good, some great, many mediocre. There are also many textbooks that offer standard solutions to common problems. Study the websites. Study the books. Don’t reïnvent the wheel and create something from scratch when you can adapt existing, proven ideas and techniques. These ideas and techniques can save you much time and enable you to build better sites.

  Especially valuable are the techniques for dealing with bugs and poor standards support. E.g. IE6 has a bug, the peekaboo bug, which sometimes wrongly hides content: ingenious designers have, often though trial and error, evolved non-obvious solutions for many bugs like this; you will save much time by finding out how to quickly find their solutions.

  Books you can learn from include:

• Compare Apples to Apples 

  Initial testing will be easier if you configure your test browsers so that their default fonts and font sizes are very similar. Otherwise you may initially waste time on differences which are not due to browser differences, but simply to configuration differences; or you may overlook differences which are due to how some browsers (mainly old versions of IE) size fonts.

  One factor makes it difficult or impossible to make default fonts the same: most browsers do not let the user choose all the default fonts. For example, IE does not let the user choose any of the CSS generic fonts, serif, san-serif, cursive, fantasy, and monospace: IE does let the user choose a proportional font and a monospace font, but they are unrelated to the CSS generic fonts. Many other browsers have similar limitations: e.g. Firefox lets the user choose some, but not all, of the CSS generic fonts. Few browsers — Opera and SeaMonkey being the notable exceptions — let the user configure them all.

  Also, three factors may make it difficult or impossible to make default sizes the same.

  • Browsers typically let one configure the size by picking the size from a list, but browsers don’t offer all reasonable sizes in their lists: for example, Firefox 3 offers 17px in its list, but Opera 10 and Safari 4 don’t.
  • Internet Explorer offers only five choices in its list, and its choices may not match choices offered by other browsers.
  • Even if the base font sizes (em sizes) were the same for all browsers, the ex sizes may be different, as may the font sizes derived by setting font-size:small, font-size:x-small, etc. The Resources > Font Metrics and Sizes page, which lists the the ex sizes and small sizes for a variety of fonts, illustrates this point: viewing that page with several different browsers illustrates how very much the sizes can vary from browser to browser.

  It may be possible to set a font size not normally offered by the browser. For example, Firefox’s about:config and Opera’s opera:config pages can be used to set font sizes which are not in the lists of sizes available to normal users. Alternatively, some browsers — notably Safari — do what all browsers should do: let the user enter the size they want if the size is not in the browser’s list.

  The Resources > Fluid Design and Font Sizes page, which discusses font issues related to fluid design, also illustrates how text looks when sized in different ways: viewing sections of that page using different browsers may be helpful in comparing the default font sizes of the browsers, so that their default sizes can be adjusted to produce more similar results.

  It should be noted that setting the same default font size in different browsers does not guarantee that a page will have the same font size in these browsers. For example, this author observed that, when the default font size was set to 17px in both Firefox 3 and Opera 9, normal text was indeed the same size, however, text sized using font-size:small in CSS was not the same size. Using percentages of the default size appears to produce more consistent results: i.e. font-size:80%; will produce more consistent sizes in various browsers.

  It is still essential, of course, to test the site with a variety of font sizes, but this should be done only after resolving problems unrelated to font size.

• Make a Formal Test Plan 

  Plan how you will test a site. Create a checklist. And follow the plan.

  For example, the test plan might define three types of testing: initial, secondary, and tertiary:

  • Initial testing is done early, after a small number of typical pages have been created. The purpose of initial testing is to make sure that the design works. If there is a fundamental flaw in the design, this is the time to fix it; if there is a problem with a certain browser, this is the time to cope with it..

    Initial testing begins with the use of automated test tools. This is following by tests with browsers that are highly compliant with standards, then with major browsers that are less compliant with standards, and finally with all the remaining browsers in the test suite. Testing should be comprehensive, and testers should try hard to make the design fail.

    It is critical to use automated test tools as the first step in formal testing. It is surprisingly easy to make broken pages which look right; automated testing saves time not only by helping to find out why pages aren’t rendered as expected, but also by helping to identify problems in pages which look perfectly fine.

    Initial testing does not end until problems have been fixed

    Initial testing may involve the client, e.g. to enable the client to review the design: many people are unable to envision something until they see it in action, and it is not uncommon for a client to see initial work and realize that it was not what they expected, or that it has unexpected usability problems. (Changes at this point may be chargeable, assuming that the client signed off on the initial design.)

    Caution : problems can lurk in a site that looks fine, so testing may miss problems. It is therefore important to maintain a neutral or skeptical attitude during site development and testing.

    Here is a sample test checklist:

    Test Checklist

    Instructions: Show which tests to do by checking the 1^st checkbox in each pair of checkboxes. Put any special instructions for testing in a test log file. Show test results by putting a checkmark (pass) or an X (fail) in the 2^nd checkbox. Put details about failures in the log file. Attach this form to the log file.

    Site

    Date & Name of Tester

    Automated Tests

    HTML/XHTML/XML Validation

    CSS Validation

    Code Checks

    Link Validation

    Browser Tests

    Standards-Compliant Browsers

    Chrome

    Firefox 3.6

    Firefox 3.5

    Firefox 3.0

    IE 8

    Opera 10

    Safari 5

    Other Browsers (Major)

    IE 7

    IE 6

    Other Browsers (Minor)

    Firefox 2

    Firefox 1.5

    IE 5.5

    IE 5.01

    Konqueror 4

    Mozilla 1.7.13

    Mozilla 1.4.1

    Opera 9

  • Secondary testing is less formal, and is done repeatedly throughout the development cycle whenever the designer wants to check their work. The purpose of secondary testing is to see if the work done to date is okay.

    Secondary testing begins with the use of automated test tools. This is following by tests with browsers that are highly compliant with standards, then perhaps with major browsers that are less compliant with standards. Minor browsers are not tested unless there is some reason to suspect that there may be a problem: secondary testing should be quick and therefore less comprehensive than initial testing; it is assumed than initial testing has already found and fixed critical problems with minor browsers. If a problem is found, it may be fixed then, or it may simply be added to a to-do list.

    Secondary testing may end with an interim site which is made available to the client, who may wish to request changes, but it is important to make it clear that the work is incomplete and may have outstanding problems. (Changes requested by the client at this point may be chargeable, assuming that the client signed off on the initial design.)

  • Tertiary testing is done before deploying the site. The purpose of tertiary testing is to make sure that the site is ready for use.

    Tertiary testing begins with the use of automated test tools. This is following by tests with browsers that are highly compliant with standards, then with major browsers that are less compliant with standards, and finally with all the remaining browsers in the test suite. Testing should be comprehensive. Problems should be fixed, with testing repeated on pages affected by any changes needed to fix the problems.

    The client must sign off on the site when final testing has proven that the site meets the requirements.

  The test plan should also define how changes will be handled, and how the site is to be re-tested:

  • It is most cost effective to add desired changes to a to-do list, and then to schedule the changes so that related changes and very minor changes are done at the same time.

  • It is critical to establish the scope of changes in order to determine what must be re-tested. In some cases, e.g. when changes are related, only one page or a set of pages need be re-tested; in some cases, e.g. when changes are very minor, it suffices to test with only one browser, or with a small set of browsers; and in some cases it is necessary to re-test the entire site with the full test suite. In the last case, as many changes as possible should be done together so that as many changes as possible can be tested at one time.