Resources Design

Error: JavaScript is needed to render this site: please enable it.

This gives miscellaneous information about design issues, especially those design issues which simplify testing websites.

This page is organized into these sections:

NB​: this page offers suggestions which you won’t 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 isn’t 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

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

Make it Fast

Make your sites load fast. If it takes too long to load pages, users will flee your site and go elsewhere.

Minimizing and optimizing images is a key step in mak­ing sites fast: only use images to make your sites effective, make image file sizes as tiny as possible with acceptable image quality, and reüse images throughout a site.

Minimizing embedded fonts is also a key step in making sites fast, especially for the first page which users access, since embedded fonts are downloaded with the first page, then cached for higher speed with subsequent pages.

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.

NB​: to learn why you should design to the standards, see Using Web Standards in your Web Pages.

NB​: compliance with standards can have extremely subtle, unexpected consequences which can result in pages not work­ing as expected even when there is nothing wrong with the code. For example, there are some browsers which are highly standards compliant which 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 troubleshoot, 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’s 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’s possible that the problem is due to a browser bug: however, it’s far more likely that the brow­ser is behaving properly in strict mode, but that the brow­ser doesn’t behave as you expect because your understanding of some ele­ment of the standards is faulty. When this happens you should use such problems as learning opportunities: your objective should not only be to make the page work in strict mode as expected: your should also learn where you went wrong so that you are less likely to repeat your errors in the future.

There are good resources for learning and designing to the standards, for example:


Once it was hard to make pages valid, because poor standards support entailed the use of non-standard features. Making invalid pages today is rarely justified. Old software tools such as Microsoft’s FrontPage create badly broken code; modern tools are much better.

A special challenge is legacy sites, like this site, which were created long ago. Such sites often have accreted code needed only by extinct browsers. HTML often follows Transitional standards, instead of Strict. And CSS can be especially bloated and complex, because it had to overcome serious CSS defects in ancient browsers. Even code that was well designed can devolve into chaos. Sites can, therefore, become more costly to maintain as time goes on, especially when not maintained by the original designer(s). At a certain point it may make sense to redo the code using modern practices. It may be hard, however, to get management approval for such a redesign, since management may not understand the issues; it may, therefore, be better to delay the redesign until the need arises for a major site update which has clear, tangible benefits that even a manager can understand ;-)

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’s 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.

Don’t assume that there are no errors in a page that looks right: it’s common to believe that, if a page looks right, it’s right. First, some errors may not be obvious. Second, a browser that doesn’t 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’s resized, or when it has 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 isn’t 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 doesn’t 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 IE 4 and Netscape 4 clearly don’t 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.

IE 5 is a problem because its support of standards is abysmal compared to more common browsers, but some people still use it: in July 2017, 0.8% visitors to this site used IE 5, and 0.8% is a bit too large to ignore. IE 6 is a much more serious problem, for although it supports standards much better than IE 5 does, it has many defects: and in July 2017, 5.6% of visitors to this site used IE 6, and 5.6% is far, far too large to ignore. Fortunately this site supports IE 5 and IE 6 because it was originally developed when many people used these browsers, so this site has special legacy code to cater to their differences. New sites can ignore IE 5, but deciding to ignore IE 6 is fraught with peril.

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 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 won’t 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’s okay to use it, especially if the element is simple and well-defined. Nonetheless, using anything which isn’t universally supported complicates testing, and using anything which isn’t 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 a some elements of standards are optional, ambiguous, or unspecified, b layout is affected by user settings, PC configuration, and display technologies, or c 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:

Choose Font Stacks Carefully

Choose your font stacks very carefully, with a focus on choosing fonts which are legible and available. For details about this, see Fonts Choices : Suggest Alternate Fonts in a Font Stack.

Avoid Complex Font Sizing

Avoid complex font sizing: setting sizes in complex ways, or setting a myriad of sizes, can cause unwanted and nonobvious dif­fe­ren­ces in how browsers size fonts, especially with older versions of Internet Explorer.

NB​: actual font sizes will vary from specified font sizes due to sub-pixel rounding.

Here are a few guidelines for choosing 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 about 0.68em, tinier even than the standard small size. 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 position­ing, which isn’t supported by IE6 and its progenitors.

Experience will teach you much about browsers differences, but good up-to-date reference books are essential. E.g.:

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 brow­sers that you can reasonably exclude these people from your websites.

If you must use something that is poorly supported, use a proven work-around that works with all browsers. E.g. if you need getElementById(), which old versions of IE don’t 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 work-around 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’s harder to make good software — and to maintain it — than it’s 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”. Moreover, 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 can’t cover all possible problems.

Experience will teach you much about browsers differences, but good up-to-date reference books are essential. E.g.:

Using software components supplied by others can be useful, but if they become outdated and you can’t 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 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. 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 brow­ser snif­ing, since this isn’t entirely reliable.

For more information about brow­ser snif­ing and the alternatives, see Resources Browser Sniffing.

Avoid Plugins

Avoid plugins, since plugins are not universally installed, and because some users have versions of plugins which have se­cu­ri­ty defects.

One special problem is that makers of some plugins have chronic problems with update procedures which don’t work, resulting in many users uninstalling the plugins in frustration, or continuing to use old versions which are unsafe.

Another special problem is that many users have certain plugins disabled, choosing to enable them on a case by case basis only, and so don’t work by default.

Be Careful with Dark Themes

Pages with dark themes can look quite attractive — perhaps because they are so different — but there is a problem: when switching from a window with a light theme to a window with a dark theme, the user’s eyes struggle to adapt to the severe change in colour themes, and this can make it harder for the user to quickly absorb the content of the second window. There is a similar problem when switching from a window with a dark theme to a window with a light theme.

Browser Oddities & Stupidities 

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

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.

Most 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 don’t (or can’t) keep their browsers up-to-date.

The biggest problems are IE older than IE 9: other browsers 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, IE8, or IE9, because IE7 and IE8 are not available for any version of Windows older than XP SP2, and IE9 isn’t available for any version of Windows older than Vista).

There are work-arounds for many bugs — e.g. the notorious IE peekaboo bug — and there is much information on the Internet about these bugs and their work-arounds. 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 can’t be eliminated. For more about this, see the Wikipedia article Bypass your cache.

The caching problem can also affect users — or worse, users who are clients — who may go to an updated page and find that the page is displayed wrongly due to caching. Users — and clients — may think that the designer has done a poor job when updating a page, either by not making a required update, or by doing an update wrongly. It may be helpful to prepare a FAQ which explains the caching problem and what to do about it, so that when someone complains you can cite a ready-made explanation: for example, see Your Updates - Why Aren’t They There‽.


Most browsers use the DOCTYPE to decide how strictly to apply standards. Using the DOCTYPE for this purpose isn’t 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 inline images.

One facet of using DOCTYPEs for this purpose is that 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.

Something which complicates the use of DOCTYPEs is that IE8 and IE9 honour the DOCTYPE differently if a meta tag appears telling IE8 or IE9 to render pages like some other version of IE. For example, the DOCTYPE could indicate standards mode, but the meta tag could tell IE8 or IE9 to emulate IE7, which would result in pages not being rendered as strictly as they could be. More information about this is available in Microsoft’s Defining Document Compatibility.

Another IE8 issue is that the user can force it into an IE7 mode, making it use an IE7 user agent and making it render pages more as IE7 would: though likely not exactly as IE7 would, so a page could be rendered differently in IE7 than it would in IE8’s IE7 emulation.

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 don’t 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 perversely make the sizes of <h5> and <h6> headers smaller than the size of normal body text. This counter-intuitive behaviour is specified by the CSS3 and proposed CSS4 specifications. See Sizing Headers for suggestions about setting header font sizes.

Generic Fonts

As discussed elsewhere, CSS recognizes five generic fonts: serif, sans-serif, cursive, fantasy, and monospace, with more being considered. To test a page which is styled using these fonts, it’s 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. Indeed, the CSS Stan­dard says User agents are encouraged to allow users to select alternative choices for the generic fonts. Sadly, only two modern browsers, SeaMonkey and Vivaldi, let the users select all the generic fonts. The inability to select the generic fonts can complicate testing.

JavaScript Engines & DOMs

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

A problem with JavaScript code is that different browsers may implement the JavaScript differently. This can happen, for example, if a JavaScript engine has a bug, complies with a newer JavaScript standard, or supports non-standard elements.

Experience will teach you much about browsers differences, but good reference books which cite browser dependencies are essential. E.g.:

Here are some considerations:

Idiotic CSS

The CSS3 shape-outside:url() and shape-outside:attr(src url) do not work with local files, and therefore are useless.

Non-Standard CSS

Most browsers support some CSS which isn’t 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, can’t 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.

Marker positioning can also be a serious problem. A marker is the number, bullet, or other character which normally appears to the left of each item in a list. The CSS 2.1 specification doesn’t say how to control the size of the indent for each item, nor does it say where to position the marker within the indent: instead, the CSS specification leaves this up to each individual browser.

Browsers control this through various combinations of <li>, margin-left, and padding-left properties, and different browsers do this differently. Indeed, different versions of the same browser may do it differently: IE4 does it one way, IE5 another, and IE6 yet another; Opera 9 does it one way, Opera 7 another, and older versions of Opera yet another; the Gecko browsers, fortunately, appear to be consistent.

If, therefore, you wish to control the <li> indent size and marker position, you must be prepared to use different CSS for each version of each browser, and to test with each browser and each version. You must also be prepared to update each site when a new version appears which handles marker position differently. This is possible, but onerous.

Note that CSS 2.0 defined a way to control the marker indent size and positioning, but no browser implemented it, so this was dropped in CSS 2.1. CSS 3 has re-introduced it, but it will be useless until most browsers support it, which won’t be for many years, perhaps when all of today’s designers have retired.

An example of CSS which is peculiar to a single browser is Internet Explorer’s alpha transparency filter. Though it’s only supported by Internet Explorer (and not by IE 8), it’s 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 isn’t 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 a new standard is the <canvas> tag, which is defined in the 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 isn’t 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.

Flashing objects with frequencies from 2–55 Hz can trigger epileptic episodes in some people. For this reason, the archaic HTML tags <blink> and <marquee> should never be used, the CSS 2 text-decoration:blink should never be used, and flashing effects using other techniques should be used only with extreme caution.

Another example of archaic HTML is the background attribute of the <table> tag: this attribute isn’t 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 shouldn’t 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 & 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 isn’t 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 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 used by some, doesn’t support it: for this reason it’s 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 doesn’t support it. Code unique to Internet Explorer must therefore be used. Code to get information about plugins should be encapsu­lated 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 shouldn’t use non-standard JavaScript, except when it’s 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 shouldn’t.

Many designers create pages which contain JavaScript errors, especially when designers consider the errors to be harmless: an example is assigning a value to an undeclared variable. This creates two problems. First, it may worry users who notice the errors, because they will worry that there is a problem with their PC, or a problem with the site. Second, it makes it harder to detect errors which are not harmless, because the serious errors are hidden within a pile of supposedly harmless errors. There is no reason to allow JavaScript code to have any errors, and every reason to ensure that there are none.


Some plugins are not available for certain browsers. For example, many plugins are not available for some 64-bit browsers. These creates obvious design problems for sites which depend on the plugins being installed.

Chrome Oddities & Stupidities 

Insecure Pages

Chrome 68 (and later) says a site is insecure if the page is an http:// page. This is an annoyance.

Background Colour Defects

Chrome 68 (and later) darkens background colours on some PCs, e.g. turns white to pale yellow, and this is beyond annoying: changing the background colour makes it harder to use Chrome to test local sites.

Page Defects

Chrome based browsers may produce defects on pages. For example, 1 unwanted underlines appear when double underlines are used to decorate links, or 2 coloured edges appear where nothing in the site specifies such edges. Sometimes this happens when a page is online (remote), but not when it’s offline (local), or vice versa. This is clearly caused by bugs in the browser engine.

The unwanted underlines can only be avoided by avoiding double underlines in links. Other defects can sometimes be avoided by trial-and-error tweaks of the CSS, e.g. by specifying redundant back­ground colours, but this is complicated by the fact that sometimes it matters whether pages are online or offline.

Refresh Defects

When refreshing a page, Chrome based browsers ofen jump elsewhere within the page.

Firefox Oddities & Stupidities 

Automatic Image Resizing

Like many browsers, Firefox can automatically resize (shrink) images which are too big to fit within the browser win­dow. 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, SeaMonkey, and Firefox 1.5: but it’s harder to do this in later versions of Firefox because, in an act of appalling stupidity, the Firefox makers removed the option from the Preferen­ces in Firefox 2: resizing can now only be disabled using Firefox’s arcane about:config page.

To disable resizing with Firefox, it’s now necessary to set the following about:config property to false:


CSS Default Fonts

As discussed elsewhere, CSS recognizes five generic fonts: serif, sans-serif, cursive, fantasy, and monospace, and more are being considered. To test a page which is styled using these fonts, it’s 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 progeni­tor, 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 the generic fonts should consider using SeaMonkey or Vivaldi instead of Firefox for testing, since SeaMonkey and Vivaldi still allow 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 render­ed in the same size. For example, the text size resulting from font-size:small may be he same as 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, looking for discrepancies:

medium small x-small xx-small

Internet Explorer Oddities & Stupidities 


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.

Firefox example Internet Explorer example

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–9: in standards mode, IE 6–11 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 isn’t 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, with more being considered. To test a page which is styled using these fonts, it’s 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 doesn’t allow the user to select them, so if IE picks fonts which can’t 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 ac­cordingly, 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 doesn’t do; and much that it does do, but wrongly. Users should upgrade, at least to IE 6.0, but many users won’t, or can’t.

Some major 5.01 CSS problems are: it has a broken box model; it doesn’t 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.


As discussed elsewhere, browser makers have chosen to use the DOCTYPE to decide how strictly to honour the stan­dards. This use of DOCTYPEs isn’t prescribed in the standards: it’s 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’s not on the first line, IE will render pages in quirks mode.

To avoid this problem, it’s 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 isn’t just hard, but impossible, and therefore design a site assuming that the font size will always be exactly what they specify. However, it’s possible to override the font size in Internet Explorer, and it’s 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.

NB​: 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’s easy for both designers and users to believe that it isn’t 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.

A problem with all these methods is that browsers tend to require users to pick their preferred font size from a list, and the list may not have the size which the user would most prefer.

NB​: 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 signifi­cance 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 posi­tions 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, but this can make it harder to test sites, because it can obscure errors, and because other browsers likely won’t behave the same.

Internet Explorer’s tolerance of HTML and CSS errors is arguably the major reason why so many designers create so many sites which appear to work with Internet Explorer, but which fail to work with other, less tolerant browsers: designers think that their sites are fine because they see no problems, forgetting — or not knowing! — that Internet Explorer hides problems.

Another important reason for the creation of so many sites that fail with other browsers, perhaps, is that many designers hold the view — perhaps subconsciously — that their version of Internet Explorer does what is right.

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

JavaScript Engine

The 32- and 64-bit versions of IE may have different engines: this is true, for example, of IE 9. The fact that there are different engines creates the possibility that the 32- and 64-bit versions of IE9 could behave differently.

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 isn’t named.

It is therefore better to test first with browsers which provide more information about JavaScript errors — e.g. Firefox, 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 se­cu­ri­ty options which give users a lot of control about what IE will allow, on a site by site basis. One aspect of this is that the se­cu­ri­ty 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 se­cu­ri­ty options.

Running Multiple Versions

Unlike most browsers, Internet Explorer stupidly allows only one version of Internet Explorer to be in­stalled 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 isn’t 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.


Internet Explorer doesn’t 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 don’t agree.

Automated Tools 

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

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 

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, which 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 will 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 isn’t generally available — and knowing this would be very helpful because different versions have different capabilities.

A conservative strategy would be to deploy an initial site that supports very old browsers like IE 6, 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 doesn’t impair the site’s function­ality. 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, hence 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 Firefox does something properly which other browsers don’t, making your site work with Firefox will help ensure that your site will continue to work properly when other browsers catch up to Firefox .

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

NB​: modern browsers are very standards-compliant, so problems with non-compliance chiefly appear with older browsers; in June 2018, many people continue to use old versions of Firefox and Internet Explorer.

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. if you test with the latest version of Vivaldi, your don’t have to test with the latest versions of Chrome and Opera.

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:

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 brow­ser must be handled differently. Following is information about installing and running these test browsers:

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

NB​: 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.:

Opera [Windows] 

Installing multiple versions of Opera is simple for versions up to version 12. 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.

Installing multiple versions of Opera for versions 15+ is something this author has been unable to do: installing multiple versions appears to work, however, attempts to run old versions often results in the latest version being run instead. Opera Software clearly isn’t trying to help developers cope with multiple versions of Opera. If you have found out how to do this, please contact this author.

Installing multiple versions of Opera for versions 22+ is even more difficult, since these versions have an auto-update feature, and there is no obvious way to disable it, so Opera will automatically update older versions that are really needed for testing sites.

Internet Explorer [Windows] 

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

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’s 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 won’t let you down­load its Player unless you answer a large number of unnecessary and irrelevant questions.

The free VMware Player has a number of limitations, including the fact that it can only run a pre-built virtual machine: it can’t create a new virtual machine. For more flexibility you need a product designed to create test environments, e.g. VMware WorkStation for Windows or Linux.

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

Design Considerations 

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



 Top of Page         Legal Notices