Testing your pages
Something you simply cannot skip is the testing of your pages before you let them loose on the world. While it would be impossible to test every single possible technical configuration, there are things that must work in broad areas, and things you can go around.
This page was last updated on 2012-08-21
While the current generation of browsers have indeed all done an excellent job of supporting established » web standards, you must remain aware that there will always be a proportion of your website's audience using browsers that don't support the latest hot web technologies, such as Ajax. You must cater for these people as best you can. While it would be an ideal situation if everybody diligently downloaded the newest browser on each release, it is simply not acceptable to expect this. You can encourage people to upgrade, yes; but never demand it. Your site has to remain usable to users still, for whatever reason, browsing with old software.
Graceful degradation means your page will not be too adversely affected if viewed through an older browser. This means keeping your site accessible to everyone, from the guy on the cutting edge of Internet technology to the guy sitting in some outdated college computer room. It doesn't need to look lovely, just viewable. If you write valid, structural HTML or XHTML, this should come as standard, which is nice. There are also a bevy of safeguards you can utilise to help realise this goal.
The amount of people with browsers below version 4 is thankfully low enough — you can design a site that is usable to them but still looks modern to the best browsers. HTML 4.01 and CSS are the cut-off points, really. The more recent » W3C technologies have been designed to be backwards-compatible — that is, work acceptably in older browsers which lack support for them. This means that using CSS for the presentation of your site is entirely recommended. Browsers that cannot do CSS will still be able to render the HTML document, meaning your page stays readable, it just won't look quite as swish.
While at the end of the 90s the trend was to use hacks and lots of presentational markup to have your site looking comparable across browser versions, this practice is not advisable anymore. Use CSS to pretty-up your pages for readers with capable browsers, but don't fill your code with lots of extraneous
font tags just to service the users of old browsers (while dumping a large filesize and compatibility penalty on those with a modern browser). It's ok to have your pages looking bare in old browsers — making sure they're accessible should be a much higher concern.
As mentioned already, you should have a good knowledge of which tags came with which HTML recommendation. The list of HTML 4.01 tags is a good starting point. Since you probably will be making use of some of these tags, you should check your site still functions acceptably in a browser that lacks support for these new tags. Your perceived audience should give you a good indication of what browser level you should be trying to support. For the vast majority of websites, authoring with HTML 4 tags and stylesheets is not only acceptable but encouraged. Those of you hoping to make use of highly advanced CSS should make sure that your readership are clued-in to the technology. Coding a site about antiques or gardening using cutting-edge techniques is not always going to be a good idea.
Also watch your usage of proprietary tags like IE's
<marquee> or Netscape's
<blink>. It shouldn't be too hard to avoid using these tags completely. Using proprietary tags causes severe accessibility problems as users who have chosen a different browser will not be able to get at some parts of your site. Limiting your audience like this is both foolish and unfair.
Your page should look similar across all of the major browsers — Mozilla Firefox, Internet Explorer, Safari and Opera. It may look better in certain browsers due to the quality of their support for various standards, but it should be your goal to get your design looking decent in all of them. Designing to standards, instead of individual browser quirks, should help you on your way. If you can, test your pages in a text-only browser too, like » Lynx.
Check out our Browser Support page and chart for a generalised look at which browsers support what. Your decision on what level of the technology you want to use will have to be made up depending on your requirements and audience. Of course, if you want the maximum and most diverse range of readers, aim as low as possible. If you want some hands-on testing time with some » older browsers, you can download them from Evolt.
Don't use the old 'best experienced in browser X' cliché, you'll be driving visitors away for no reason. A well designed site has no need for weak excuses like this.
If you hand-code and aren't very careful, or if you use a program that naturally outputs ganky code (like a lot of WYSIWYG editors), the way a browser displays what you give it can cause headaches when things don't go to plan. There are definite problem areas — tables for example — but even a simple mistake might mess pages up for some of your readers.
Some browsers are more forgiving — you can get away with a lot of things in Internet Explorer that you can't in Firefox. For instance, you can just close tables with
</table> and leave out the intermediary
/trs. In old versions of Netscape Navigator, your entire table will disappear if these are left out. If Explorer wasn't so lax on the issue, I'd imagine the quality of many people's code would improve.
Your tag syntax has to be correct. That means, if you open two tags, like
<b><u>, you must close them in the right order —
</u></b>. That is a simple example, but apply it to a complex table and you'll see what happens when you mess this up. Remember: the tag most recently opened is the tag you close first.
The easy way around this problem is to get a HTML editor with a built-in HTML validator. This will check for syntax errors and unclosed tags, sometimes even telling you your mistakes as you type. You should also test your pages online at the W3C's » html validator, a service which comes highly recommended.
Using the 216 web-safe colour palette used to be a really big deal. Nowadays it isn't that much of a problem. Graphics are a different story though. GIFs are less of a problem, because usually a GIF will be simple and not require more than a couple of dozen colours at most. You should try to save your GIFs in the safety palette. This will ensure that they are really small too.
It is simply impossible to have JPEGs looking the same at 256 colours, because they use such a huge colour palette. In fact, JPEGs usually look really horrible at 256 colours, so it's a good idea not to have them all over your page, and have links to them (or use thumbnails), so the poor low-depth people can spare themselves from seeing them.
Having to scroll sideways is one of the worst things that can happen at any site. Whether it be due to bad design or bad judgement, they are something to avoid like the plague.
Look at web usage reports. These are checks on the way people browse the Internet — what browser they use, their colour depth, their resolution etc. At the moment the prevailing resolution setting is 800x600. HTML Source is designed to fit within this. A lot of people are moving into 1024x768, the next highest resolution. Very few people are left on 640x480, the lowest resolution found in modern monitors. This percentage of people is so low that you can discount designing your site for this size. So, design for 800x600. Any higher and you'll be annoying too many people; any lower and you'll be wasting valuable screen space.
Next, decide whether you want your page to take up the whole screen (called a liquid layout), or whether you want your design to be more rigid and fixed to a certain width. Both have their benefits. Making your design liquid means your page will adapt to the resolution of the reader, but is also harder to write in, as you have to go and check all the resolutions to see if your content still fits and looks good. I generally prefer fixed designs as you have more control over the page's layout. A liquid layout is the ideal situation, so if you can design a layout that's resolution-independant, go for it.
Otherwise, make the widths of all your page elements about 760 pixels wide. This will be small enough to fit nicely onto a 800x600 screen (and still fit the vertical scrollbar in). If it fits into that, that's fine. No more testing to be done.
Something you may not realise is that without the images on your page, everything might get laid out wrong. Many people turn images off in their browsers for increased speed. There is an option somewhere in your browser's configuration screens to turn image loading off. Have a browse around your site with this enabled and see how many errors this has caused.
alt attributes stretch the areas where images are meant to be if they are turned off, leaving you with a massive space across the screen. Fix this by always adding
width attributes, all found in further attributes.
If you have specified a
background to either your entire page or to a table cell, you have to check whether the text is still readable without it. Add a similarily-coloured
bgcolor in it's place, which will appear first, then the
background will go over it once it has loaded, keeping everything readable all the way.