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.
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.
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
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.
em
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
.
A percentage would be inappropriate in this case,
and an absolute pixel size would always be wrong.
max-width: 65em;
It used to be recommended that one always explicitly give a
and width=
attribute with each height=
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 img
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).
em
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.
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.
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.
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
,
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
<hr />
style instead.
If a solid bar really is significant though
(e.g. an HTML-to-voice translator should announce its presence),
do use h2 { border-bottom-style: solid; }
.
<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.
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.
accessibilityfor 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.
progressive enhancementnot
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.
,
or You need to enable javascript
).
While an improvement over failing miserably,
this approach moves the blame to the user
from the web page designer where it really belongs.
You must use IE to read this
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.
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.
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.
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
with
Click here for more web page style suggestions
.
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
.
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.
Compare:
<a mailto="user@math.uwaterloo.ca">
<a mailto="user@math">