skip to primary navigationskip to content

Setting up your web files

The next step is to set up the initial set of web documents (HTML files, images, etc.) within the public_html folder. You can check that the pages are as you intended by viewing them locally with a browser such as Firefox or Microsoft Internet Explorer™.

Structure of the public_html directory

Each directory and sub directory should have a file called  index.htm or index.html that is the 'entry' page for the directory. In particular, the Society's main public_html directory must have one, since that is effectively the Society's home page.

HTML pages

At a minimum, HTML documents should have contents similar to the following template:

     <title>A suitable title</title>
     <link rev="made" href="mailto:contact@wherever">
     <h1>Main heading</h1>
     <p>the text of the document</p>
     <p>return to <a href="/">University of Cambridge home page</a>
     <address>Pretend society, 
     <a href="></a><br>
     last updated April 2000</address>

The href in the <link> tag should be the Society's email address which is to be used for reporting problems with the document, whether or not an e-mail address is included elsewhere in the document. Some browsers provide a comment facility which will email to that address; it will at least be visible to anyone viewing the HTML source code for the displayed document.

Note that all hostnames in e-mail addresses, in this and other contexts, should be quoted in full, e.g. notsoc-xxxx@lists

Note that the <title> text is particularly important. It is ranked highly by search engines to identify documents, is saved in browser bookmark files, and is displayed in a graphical browser window's title bar. Thus, it should be thought about carefully, so that it can be recognised out of context. Thus a Society's top-level index.html might well have

     <title>University of Cambridge Xyz Society</title>

but with a simplified version as the main heading

     <h1>Xyz Society</h1>

Links to other documents

Links between documents within a Society directory or between it and its subdirectories should use relative URL paths, so that the documents remain portable between servers (as long as the relationship between directories is maintained). This should also allow links to be checked by running clients on the MCS to view the documents as local files. Note that links may appear valid on a PC or Macintosh when they may not work on the web server, for example, if links contain uppercase or illegal characters. Recheck links via the web server once new or updated files have been copied across.

Assuming the directories (shown in upper-case for clarity) and files (shown in lower case)


then to refer to other files from the file index.htm, use

     href="misc/index.html" or href="misc/"

while the files in the misc directory could refer to the files in the parent directory as

     href="../index.html" or href="../"

Note that directories and files should be specified in lower-case throughout in URLs referring to societies directories, that "/" is used between components of the file specification (not the MS-DOS/Windows "\"), and that the URLs are effectively the filenames of the target files relative to the location of the files containing the references.

The server's home page (i.e. should be referenced with href="/" rather than with the full URL. To reference a page elsewhere on the server, in this case an online document from the UIS, you should use a format similar to this:


Standards and accessibility

As far as possible, documents should use facilities in the HTML 4.01 standard transitional level ( (Old browsers may not handle newer HTML tags well but ought to degrade them to something usable.) Note, though, that some web authoring tools (including word processor add-ons) may use non-standard HTML when creating an HTML file, without even mentioning that they are doing so.

Remember you cannot rely on readers of your documents using the latest versions of browsers or having image loading enabled by default, or even available to them. You should therefore be cautious about using browser-specific extensions. Pages ought to be accessible to disabled users - framed sites and those heavily dependent on JavaScript, Flash or Shockwave can present great difficulties for disabled access. To ensure pages are accessible, follow the guidance given by the W3 Consortium at

Plain text documents

Plain text doesn't look as nice as documents with full HTML formatting, but may be useful at times, especially when layout including e.g. column alignment needs to be preserved, or for transient information for which the effort of conversion to HTML is not justified.

A better alternative may be a minimal HTML document (with appropriate title and main heading) containing the text and using <pre> </pre> (pre-formatted text) tags around the otherwise raw text. Note that some characters are handled specially in pre-formatted text (but not in plain-text files!), and need to be replaced by their HTML equivalent, i.e.

& need to be changed to &amp;
< &lt;
> &gt;

The line length of plain-text files (and pre-formatted text in HTML) should be kept to less than 80 columns, since long lines will not be split automatically and text-only WWW clients are still quite widely used on terminals which typically have a line length of 80 columns (and in some cases, insert an extraneous blank line when they see a line of exactly 80 characters). Lines longer than 80 characters may cause printing problems.

Image files

GIF-format and JPEG files are widely supported. PNG files are supported by newer browsers.

Bear in mind that some people have slow network links (especially those using dialup access). Avoid large inline images unless they are an essential part of the information, and consider making just the image into a separate file and include a note (e.g. "(500KB!)" ) with the link from the parent document. In other cases, include a reduced-size thumbnail image adjacent to (or as part of) the link. Limiting images to 8-bit colour rather than 24-bit will reduce the size of the file substantially, using optimisation and compression will further reduce the size of the file.

Avoid the gratuitous use of fancy icons (e.g. coloured circles instead of the bullets used by <LI> entries in unordered lists). For example, do not use inline images as the sole component of descriptions, so that only people who can see the images can select the links.

When using inline images, if they are important to the information content of the page, include an alt="[description]" note in the <img> tag. The description should be enough to indicate what the image is, so that, if image loading is disabled, the user can decide from the description whether to load it manually. For purely decorative images, use alt="", which, for text-only users, will hide the existence of the image.

Words included as images are not indexed by search engines. Many (but not all) search engines will index words included in alt tags. To ensure that your text is available and accessible, don't lock it away in graphics but make it available, perhaps as an alternative text view of information. This is particularly important if you make extensive use of Flash or Shockwave presentations.

Some icons are available for use, for instance a 'new' marker is in the selection and may be inserted as:

     <img src="/icons/local/new.gif" alt="[new]">

The following icons are amongst those available for use:

new: src="/icons/local/new.gif"
updated: src="/icons/local/updated.gif"
University identifier:
(with cream coloured transparency)
(UnivHeader1.gif and UnivHeader3.gif
are also available, being bigger or smaller, respectively, than the standard one)


Coloured backgrounds

Colour backgrounds are widely used and as their formatting is part of the HTML in a document they are an economical special effect. Be aware that some older monitors have a restricted set of colours available and usage of colours outside that set will cause unpredictable results. Pale type on black and other dark backgrounds may be very difficult to read and combinations that can be read will not necessarily print. Care should be taken with setting type colours for links and text if a background colour is to be used - ensure that you view pages on several types of computer and consider access for people with compromised vision.

Scripting and programming

Browser scripting and programming facilities (e.g. JavaScript, Java) should be used sparingly and with due allowance for (a) the wide variation in browser support (i.e. not all browsers support them) and (b) incompatibilities between different browsers' implementations of JavaScript and Java. Many users disable their browsers form using JavaScript. ActiveX should not be used.

Further Help

Further help on setting up websites and writing HTML documents can be found at