Trouble-shooting Web page HTML when things don't work

The text styles/sizes start out OK, but are wrong by the end of the page

1) Check that "start" and "end" tags are matched corectly;

I frequently put things like "this is very important" and then wonder why all the rest of the page is in bold! (The second  should have been  with a "/").

2) Check "nested" mark-up (strictly, this should only occur rarely!)

In the following contrived sequence
"Remember, <TT> this is very</TT> important",
the two "end tags" have been transposed. Whatever form of logic a browser attempts to apply, it won't ever display as intended!

Links to other pages won't work; or Images don't appear

3) Check that the filenames in the HTML-source and the site directory match exactly as regards upper/lower case.

Although the RiscOS filing system is not sensitive to the case (upper/lower) of the letters in filenames, the Unix filing system (or Unix look-alike) used by the web-server most definitely IS.

For simplicity, I prefer to use lower-case throughout; this saves me having to remember which letters if any are in upper case!

4) Check that the extensions are correct in both source and directory:

"html", "gif" or "jpeg" usually; and "zip" or "arc" if appropriate; with the extension separated from the leafname by "/" in the directory and ". " in the HTML-source.

Although the RiscOS filing system encodes the file-type separately from the filename, Unix-style filing systems expect an extension. WebPack - and TIMM at the other end - do a pretty intelligent job of associating the right extension with the right filetype, and even coping with truncated filenames-plus-extension; but they aren't 100% idiot-proof, and can still sometimes get fooled.

To be fool-proof, I tend to restrict the leafname (excluding extension) to five characters maximum (possibly six for /gif or /zip extensions).

Downloadable files and applications can't be accessed

Check (3) & (4) above: file-names have to be exactly correct.

5) If you have archives to upload, ensure your archiver program is completely shut down before using WebPack.

WebPack will only pack files within your "site" directory; it will NOT include any sub-directories. If your archiver (eg SparkFS or the read/write version of ArcFS) is still active (ImageFS operational), the archive will appear to be a directory.

Before using WebPack, click menu over an archive icon. If the second item in the menu says
" Dir. 'thing/zip' => ", you're in trouble;
but if it refers to " File 'thing/zip' => ", then you'll be OK.

6) Check for obscure filetypes or extensions.

I'm never quite sure, but I suspect that WebPack may contain an internal list of filetypes and extensions that it is prepared to recognise: if this is true, and if you've got a fancy file which is not on the list, then either it might not get uploaded, or else it might be put on the site but with the "wrong" extension.
Disclaimer: I may be totally wrong on this!!

It works locally (from hard disk) but not over the InterNet

Check (3) above: web access is case-sensitive, local access isn't.
Check (4) above: the web-site filenames my differ from the local ones.
Check (5) & (6) above: some (archive) files may not have been uploaded.

7) Check whether the URLs used in (eg) "HREF=" are absolute or relative.

If you have <A HREF="page2.html"> (or <A HREF="./page2.html"> ),
they are relative URLs, and the page requested will be looked for in the "current directory"; this will normally be the directory that holds the page currently being displayed,
UNLESS your HTML-code includes an element of the form
<BASE HREF="http://www.domain/diry"> in which case it will use THAT to look for "page2.html" in!
If you have <A HREF="http://www.domain/diry/page2.html">,
then that is an absolute URL, and hard cheese if it isn't exactly correct!

I can access my pages OK, but other people can't

(It's tempting to say "poor dummies must be using Wintel/Netscape-- tough" but this may not be entirely their fault!)

Check (4) above: ensure all extensions are correct.

DOS systems have an additional potential problem arising from their limitation of three-character extensions (eg "htm" and "jpg").
Providing your extensions are "correct" (in the Unix sense), all other browsers are supposed to implement that regardless of any of their platform's operating-system's limitations.

8) Try and check your site on as many different browsers as you can get.

This may help to pin down problems more specifically.

If images are their problem:

9) Check your image/graphics file-types.

Voyager/WebVoyage/ArcWeb can quite happily render SpriteFiles (indeed, it's less work for it, as no conversion is necessary and RiscOS will do the plotting); but if you've accidentally uploaded an unconverted SpriteFile to your web-site, it will be completely meaningless to any non-Acorn platform.

If other Argonauts can't access it:

10) Check everything!

It may be connected with a small change you've made recently (possibly to a filename): I'm hypothesising a situation where one of you is accessing the actual file, and the other's browser is accessing a cached version of a file from a previous occasion. Disclaimer: the above is really clutching at straws!

My transparent GIFs aren't transparent

11) Check that you really did create a transparent GIF in the first place.

WebGif2 (and spr2gif too for that matter) will only generate a transparent GIF if you specifically ask for it.

12) Check that Browser option "GIF89 handled by ChangeFSI" is OFF.

Menu on icon-bar telephone icon: Preferences => Web browser... and see what it says. ChangeFSI doesn't render transparent GIFs; so if this option is ON, un-tick it (and [Save]!)

Some of my links aren't highlighted (blue-underlined) [or non-links are]

If your page uses both types of anchor <A HREF="page#frag"> and also
<A NAME="fragment_id">, check that you haven't used NAME where you meant HREF or vice versa [ a mistake I frequently make :-( ].

My interlaced GIFs don't interlace

They probably do, but you won't see it happening!

Voyager/WebVoyage/ArcWeb does not render GIFs "on the fly" as they are being (down)loaded, but converts them (using gif2spr) into ordinary native SpriteFiles (regardless of whether they are interlaced or not), and then uses the system sprite-plotting routines to display them all in one hit.

Try viewing your site with another browser: I think Fresco will render interlaced GIFs; otherwise pull the curtains and lock the door (so nobody can see you) and try Netscape.

The Reply FORM doesn't work

There are two quite different "actions" for forms-submission: "client-side" which is handled by the browser (and only the more recent versions of WebVoyage support this); and "server-side" which is handled by a cgi-script on Argo's web-server.

There's an explanation of these methods of Forms as an archived text-file at
forms.zip

My ImageMaps don't work

There are two quite different processes for map-decoding: "client-side" which is handled by the browser (and only the more recent versions of WebVoyage support this); and "server-side" which is handled by a cgi-script on Argo's web-server.

There's an explanation of these methods of ImageMaps as an archived text-file at
imgmap.zip

If the problem is in client-side decoding of polygons, note that WebVoyage requires the <AREA> tag to include SHAPE=POLY not POLYGON, but some other browsers work the other way round!
A dual declaration SHAPE=POLYGON SHAPE=POLY seems to work.

Is there a way of automatically checking the code on my pages?

There is a simple validator available (for checking for mis-matched or badly-nested brackets, quotes and tags) called Validator as an archive valid.zip ,
and one for checking that all file references (HREF, IMG SRC= etc) do exist, called LinkCheck
linkck.zip
both available from my Progs Page.

John Alldred <john@protovale.co.uk> 27/8/97

Back to Home Page . . . . . . Back to "Tutors" page