W3C Validated CSS UW logo W3C Validated HTML MFCF logo

Web Page Style Suggestions

Select a topic bar to expand or collapse its details.

Strictly follow standards.

Always validate your code after making even minor changes. It might initially take a few seconds longer, but writing standard code can save a lot of work in the future, guarantee the maximum portability of the web page, and enable validators to find any real syntax errors. It will also make it much easier for others that will eventually have to make changes to your code to work with it.

And performing the validation can be trivial. Click on the HTML and CSS validation buttons at the top right for example.

Don't assume that everyone's browser works like yours.

Avoid browser-specific code. Customizing your code to take the peculiarities of each user's browser into consideration simply isn't worth it. If there is some special feature that works in IE but not in Firefox, simply don't use it.

Don't assume that everyone's screen looks like yours.

Avoid fixed font sizes; instead use CSS and percentage sizes. Users should be able to adjust font sizes to their own personal preference, not be required to read it at whatever size the page creator thought looked prettiest on their own screen.

Avoid fixed-width as much as possible. When it really is necessary to define a width, set it in em units or as a percentage, depending upon whether you want the size to be relative to nearby text or to the window's or container's width. Using relative sizes will allow pages to format nicely on whatever sized window and with whatever font size the user likes. Using absolute sizes will cause images to appear huge on low-resolution devices, and tiny on high-resolution.

Never specify an absolute width for your documents. It is okay however to provide some limits. e.g. if you don't want text lines to be ridiculously long when the user has a very wide window, limit them with max-width: 65em;. A percentage would be inappropriate in this case, and an absolute pixel size would always be wrong.

It used to be recommended that one always explicitly give a width= and height= attribute with each img to allow the browser to format the page before it has finished downloading the image. Today, those few people with such incredibly slow network connections would not want to download the images anyway. So don't do that. Instead, specify the size in the style section as a percentage of the window's width or in em units, depending upon whether the size should match the layout (e.g. 25% of the page width) or the text (e.g. 4 lines of text).

Avoid anything that might make horizontal scrolling necessary.

This page for instance sets the widths of the images as relative sizes. Make the window wider or narrower and watch what happens. Similarly making the text larger or smaller still allows things to format nicely under all circumstances, from BlackBerry to wall-screen, from PC monitor to printed page, rather than being designed to look nice only on the screen of the person that created it. Setting minimum and maximum widths (percent or character relative, but opposite to whatever size unit was used) prevents the images from becomming ridiculously small or large.

Don't assume everyone has the same context as you.

Not everyone did what you just did. Many web pages contain Go Back links, intended to return to the page that linked to it. That's fine for the authors, because that's how they navigated there, but others might have arrived by bookmarks or someone else's link, and go back will mean something completely different to them.

The simple solution is to properly label the link, which does not necessarily return to previously viewed page, as Fred's home directory, Parent page, Restart chapter, or whatever is appropriate.

Don't assume everyone sees things the way you do.

Colour isn't black and white. If you have graphics that convey information, always verify that that nothing significant will be lost if a user prints a hard-copy in black and white. Even when the page is not printed, your viewers will have varying degrees of colour-blindness and could miss your message.

Use background images carefully. Background images might not appear at all in hard-copy listings so they shouldn't include important information. And be aware that in some cases the background images might also make the foreground text difficult to read.

Avoid flashing text, animated graphics, and sound effects, which many people find annoying. If you really must have such things, provide an easy and obvious way to disable them.

Separate Appearance From Content.

Don't mix content and style. The body of any web page should contain pure HTML, which defines only what the contents are. It should not contain any code that explicitly determines how it should appear. That is the job of CSS as defined in the <style> section.

Even seemingly innocent tags, such as <hr />, should often be avoided. For instance, if you want a solid line after each subheading to make it stand out, it's better to set the h2 { border-bottom-style: solid; } style instead. If a solid bar really is significant though (e.g. an HTML-to-voice translator should announce its presence), do use <hr />.

Ancient versions of HTML provided numerous means of controlling the appearance of the web page. The result was messy and unreadable code that was difficult to change (tag soup). More often than not, tags were abused to produce the desired appearance, destroying the original usefulness of structural markup. Fortunately, by the mid to late 1990s, the idea that content and style should be separated became the common goal. Formatting tags, such as <FONT> and <CENTER>, and many formatting attributes, such as align= were deprecated and eventually eliminated from the HTML standard, and CSS became the correct way of specifying appearance. Meanwhile, the HTML syntax became stricter, making it much easier for humans to read and for machines to parse. Search engines can now do a much better job of cataloguing the contents.

Displaying a web page using a non-graphical browser (e.g. lynx) makes a good test. The result might be ugly or difficult to read, but no significant information should be lost. (There are of course exceptions, such as where the purpose of the web page is to illustrate the use of CSS.

Unfortunately, a lot of people that learned to write web pages in the 1990s haven't seen the light, and their bad style, using ancient HTML-4.01 conventions, continues to be copied by newcomers. Don't learn bad techniques; learn to code correctly right from the start.

Use CSS rather than scripting.

When possible, use CSS rather than scripting. CSS is part of the native language of web pages; if it can be used to do what you want, use it.

Using JavaScript might occasionally be easier, but some browsers don't support it and some users don't enable it. Since its effects are dynamic, whatever results are obtained might be hidden from search engines and other software that would otherwise be better able to analyze the page's contents.

The example here (which can be seen much better in a browser than in print) shows that even multiple-level pop-out menu selection can be done via CSS without the use of client-side scripts. Even in browsers that can't fully support it (e.g. text-only lynx), the menu items will all be nicely displayed rather than remaining unavailable as they might using dynamic scripting.

Use accessibility for everyone, not only for the disabled.

We're all handicapped. Ramps and powered doors are handy for everyone, not only for those that have trouble walking. That they are marked with wheelchair symbols doesn't make sense, especially when that same symbol is used to indicate things (such as parking spaces) that are strictly reserved.

Similarly, while web pages should be made easy to read by those with vision problems, there generally isn't any need to write versions that explicitly target accessibility issues. If you make it clean and simple, follow coding standards, and supply meaningful titles and alt descriptions, everyone will benefit.

Use progressive enhancement not graceful degradation.

Avoid arrogance. Don't belittle the user. As mentioned above, if a web page is designed to work well with a specific browser it will fail miserably for others. Some people alleviate this using graceful degradation, in which non-operating features are displayed with a comment indicating what doesn't work and why (e.g. You need to enable javascript, or You must use IE to read this). While an improvement over failing miserably, this approach moves the blame to the user from the web page designer where it really belongs.

Reward correct behaviour. Don't punish wrong behaviour. Instead pages should be designed to work well under all conditions, with extra features added only when it's possible. For instance this page itself works nicely without Javascript and displays just fine even on text-only browsers. But when Javascript is available, other features such as the expanding/collapsing sections, are enabled. Other pages might have tables that can be sorted by clicking on the column headers. Where this feature isn't available, there's no need to indicate that it could have worked if the user had done something different.

Following this principle will automatically make your web pages more accessible. There's usually a good reason why people decide to disable certain features on their browsers, and you should respect their choice.

Allow browsers to do things for you.

Don't defeat the browser's capabilities. Web browsers are capable of displaying things differently to different people, so don't write code that defeats this ability.

For instance, browsers know how to display quotation marks according to the local style of the viewer. In English-speaking North America, one would write: “John said ‘Hello!’ to Mary.”, whereas in England one would write: ‘John said “Hello!” to Mary.’.

If you enter the quotation marks yourself, whether as the simple ASCII characters, as the fancier ISO-8859-1, or as HTML entities, your page will be be displayed incorrectly for at least one set of viewers.

Instead, entering the quotation using HTML quotation tags allows each web browser to display the correct style: <q>John said <q>Hello!</q> to Mary.</q>

Not only will your web page look better, but you will not need to keep track of how many levels of quotation nesting you are working with, and source validators will be able to warn you should you accidentally not properly nest them.

Clearly distinguish between navigation pages and content pages.

Don't display links in hard-copy.

Hard-copy links are useless. Until everyone has e-paper, saying Click here for more information is useless (and frustrating).

On paper, most links should be displayed in normal text, not underlined, coloured, or marked specially as they are when displayed on an interactive screen. When a link really is essential, the text should include the full URL.

For instance, the last paragraph of the previous section contains My home page and Useful Info links, which should appear underlined on an interactive display. But on hard-copy, these names aren't distinguished in any way, although the second one is followed by a pair of brackets containing the URL (which isn't displayed except on hard-copy), as is my e-mail link at the end of this page.

Similarly, be aware of navigation tables, drop-down menus etc., and either eliminate them or format them usefully when displayed on paper.

Properly label all links.

Say why or what, not how. Each link that appears in a web page should indicate what its target is or why one might want to follow it. Such information can be used by web crawlers as keywords that can be used to build more useful indexes. Probably the most common and useless such keyword is click here, which generates more than a thousand million hits on Google.

Compare Click here for more web page style suggestions with See our Web Page Style documentation for more suggestions.

The latter will let search engines know that the target page might be of use to anyone looking for web page style; the former will help only those looking for pages that are related to click here.

Don't provide e-mail addresses for spammers.

Use domain-relative e-mail addresses. If a web page includes an e-mail address, spammers will harvest this data and add it to their junk mail lists. Instead, if the address is relative to the domain of the intended audience (say UW), the address will work fine for everyone on campus but will fail for anyone else.
    <a mailto="user@math.uwaterloo.ca">
    <a mailto="user@math">

Copyright © 2008,2010 Ray Butterworth, MFCF, University of Waterloo.
Send comments to Ray Butterworth [rbutterworth@math].