Writing a web site: hints and tips
This page is a collection of more advanced tips for good web design and implementation.
The emphasis is on more advanced sites and design than introduced in the
website starter-guide but there are hopefully tips here
which are useful to all who want to implement their sites for maximum portability and
functionality.
In the (so far) absence of time to write anything that might pass as
coherent prose on this subject, here's a bulleted list of do's and don'ts:1
-
Don't use
<br/> tags to make vertical separations: use CSS's
border and padding attributes instead.
-
Write in XHTML, rather than HTML 4. It's actually easier, because the rule set
is much cleaner and the tag nesting is consistent, as well as allowing you to
expand to more funky technologies like XSLT without difficulty.
-
Don't use underscores to represent spaces in file (i.e. page) names: the underscore is
harder to see and more awkward to type than a hyphen (minus).
-
Validate your HTML and CSS with the W3C tools!
-
Build pages according to semantics first and then style them with CSS afterwards:
separating style from content is possible most of the time.
-
Hide the underlying technology from the end user: content-negotiation can be useful
here since it means you can avoid having file extensions in your local links.
-
If your site is (going to be) large, having a sensible directory structure which
follows the site content structure is a good plan. This also allows you to isolate
data like common includes, script libraries, XSLT files and CSS files from the
content pages. If using PHP, you can still use the
require- and
include-type directives as if you have a flat directory structure by
setting the PHP include_path parameter. This is either specified in the
php.ini configuration file (or via a .htaccess file if
PHP is being run as an Apache module).
-
If you use PHP to preprocess your web pages, the
auto_prepend and
auto_append facilities may make your life much more pleasant. These will
automatically append a specified header or footer file to your pages, meaning that the
actual content is more independant of the containing site. Implementation independance
is a good thing! :-) These configuration directives can be set via php.ini
or .htaccess files as for the include path.
-
If you have more than one page in your site, use an external CSS file and, if
you can, put the common tops and bottoms of your pages in external header and
footer files.
-
Write your site in a web-oriented text editor rather than, e.g. FrontPage or Dreamweaver.
If you do use a more funky tool, you should still do your coding by hand — no other
method will give you the degree of control that's required for good semantic design and
standards compliance.
-
Have some familiarity with the ethos and details of the W3C web standards — the
antithesis of good design is the "This site is best viewed at 800x600 in Internet
Explorer 6" attitude. The standards aren't perfect, but sticking to them is the best
way to ensure that your site can be viewed everywhere.
-
Test your site in a text-only browser like Lynx. It may not be your "target market",
but a site that still makes sense in Lynx is probably doing the right thing when it
comes to semantic structure.
-
Please, don't use graphics to render paragraph text unless you absolutely have to. On
images which have a small amount of text, repeat the textual content in the
<img> tag's alt attribute so that text browsers and
users with accessibility requirements can also read it.
-
Flash is no longer cool on web pages. It's hacky, slow, obsfucated and can't be
guaranteed to work on the client's browser. Flash has a very poor record for functionality:
it looks pretty and keeps designers happy, but from a usability point of view it's awful.
-
Java and JavaScript have much the same failings as Flash. They are often turned off or
have their functionality restricted on the client browser. The main valid use of JS used
to be implementing rollover behaviour on link images, but this is now much more
efficiently implemented via CSS, using the
:hover pseudoclass.
-
The image
alt tag is not meant to pop up a "tooltip" as IE does — it's
intended to provide a textual alternative to the image. If you want a tooltip, which provides
additional information about the object, then use the title attribute.
-
Designers love small text, so many websites suffer from tiny, unreadable paragraphs. The
natural reaction to this is to resize the text (e.g.
Ctrl-+ in
Netscape/Mozilla), which often breaks the rest of the site and makes it look much worse than
it would have done with larger text in the first place. Keep in mind that the point of a
website is to disseminate information. Looking good is secondary, so keep the text the default
size (or larger) unless you have a very good reason.
-
It's often better semantically to use
<em> and <strong>
tags rather than <i> and <b> to add emphases to text.
Both are valid, but give it some thought :-)
-
Rendering blocks of code is often done on technically oriented sites, but the indentation isn't
maintained within
<code> tags. This leads many people to use a
<code><pre>blah</pre></code> construction — uugh!
Better is to use CSS again: declare something like
code.display { white-space:pre; display:block; margin-top:1em; margin-bottom:1em; }
and use that instead: it makes CSS styling of code blocks much more powerful and is, again,
semantically better.
-
Every web page officially needs a DOCTYPE declaration as its first line of code (view the
source of this site for an example). However, browsers will usually work without one and
do their best to still render the page accurately. The DOCTYPE tells the browser what kind of
HTML to expect: the HTML version, XHTML or whether you want the "Transitional" (read as "sloppy"
or "forgiving" according to prejudice) or "Strict" (read as "draconian" or "accurate") so if
you want to make sure that the client browser views the HTML as you intended, rather than
running in "quirks mode" as they usually will if it's omitted, then use a DOCTYPE declaration.
If you include a common header file for your pages, then this is dead easy — you only
have to add it once!
-
For some reason having a "splash page" for your site (usually a funky graphic with "click here
to enter the site" written on it somewhere) was once very popular. In reality it's dumb —
most people will find your site through a search engine or a recommended link and the splah page
is either unseen or impedes them in their search for content. Don't use 'em — I find that
putting the most regularly updated part of the site ("latest news" or suchlike) as the front
page works best, since that's what most people want to see.
-
Don't use JavaScript to validate forms — form validation isn't something to be done
client-side — it should be done on your server, where you have control over the validation
process. A good way to do this is to read the submitted data into an associative array and if
there's an error in any field, then write the data back to the form page (with an appropriate
error code) as a query string. This behaviour is easily written into a function which can be
used for all form processing and allows robust and flexible error handling.
-
Don't use cookies to store preferred language information — many web users regularly
flush their cookie cache (for example I set my Firefox browser to flush
the cookie cache at the end of each session). A better method is to use content negotiation,
where pages can be stored on the server as e.g. index.en.html or
index.fr.html. The web server will then select the appropriate page to view based
on the
langs HTTP header sent by the browser when requesting the page.
-
Use get rather than post for sending information to pages which might be reloaded: if you use post
and someone wants to reload the page (for example, a photo gallery where the photo set being
displayed is dependant on form-submitted data) then they'll get a dialogue box asking if they
want to resubmit the data. If you want the page to behave like a normal web page, then encode
the metadata in the URL as a query string rather than in the POST header.
-
Use post rather than get for sending information to scripts where security is an issue: the
opposite case from the previous example is where you don't ever want the page to be reloaded,
such as in processing payment details from a commercial site. In this case use POST: not only
will it ask the user if they really want to send the data twice, it's also more awkward to spoof
input data. Note that this doesn't amount to genuine security — anyone who wants to
spoof headers can do so, which is why you should never trust client-side validation, but it makes
it more awkward.
That's it for now. If you have any other suggestions, please drop me an email :-)