Web Design

troubleshooting

main menus

help pages

This page should be your first stop if you are having problems with your web site. It tries to address problems which crop up again and again. Of course there will be issues and problems which can't be solved with this page, but that's what the newsgroup (acom.option.web) and the demonstration sessions in the Cohen Cluster are for.

If problems are revealed, by demonstration sessions, newsgroup queries, or individuals, and seem to occur frequently then I will try and add them to this page. So do check it at reasonably regular intervals while you are designing.

One thing before we start, though. 95% of errors on web pages are caused by errors in the code. If you have a link that doesn't work - check the code of that link. Have you spelt the filename right? Included all relevant quotation marks? Closed your tags? I know that the actual act of coding can be time-consuming and, to some, rather tedious. Because of this, errors do slip in. But the first thing to do when there is an error on your page is look closely at the code which should be rendering the area of the page in question. Most of the time, it's simply a typing error. But if you've checked that and it doesn't work, try the following:

Missing Sections

This is a common problem. You've typed in all the text, but it doesn't appear on the screen, or entire sections (text and images) are missing. Or it appears in one browser, but not the other. If this happens, check the following:

1. Check colours. Sounds ridiculous but this can happen! Are you sure the text colour is a different, distinguishable colour from the background? You can sometimes forget, if you've changed the background colour in, say, a table. Or look at the two screen shots below. Here the author of the pages has defined the LINK attribute in the <BODY> tag, but forgotten to define VLINK. So after the link has been visited, the browser changes the text to its default VLINK colour - and the text seems to (almost) disappear.

Screen shot of page with 'vanished' visited link

2. Check </TABLE> tags. If the text appears in Internet Explorer but not in Netscape, the most likely explanation is that you've omitted a closing <TABLE> tag. If you know that the missing text corresponds to what you thought was a table, this is almost certain. Check all tables are correctly closed, and nested. Follow this link if you've forgotten how tables should be structured. Be extra-careful with nested tables; that is, a table itself contained within a <TD> tag, which often happens if tables are used for page layout purposes.

3. Check other punctuation. Many problems on web sites are caused by coders forgetting insignificant-seeming bits of punctuation; particularly angle brackets (< >) and quotation marks ("). For instance, can you see what is wrong with this code? All it produces is the line of text at the bottom.


    <P ALIGN="right>Film director Stanley Kubrick</P>
    <IMG SRC="kubrickpic.jpg" alt="Kubrick">
    <P>Director of classic films such as <I>"2001"</I> and <I>"Doctor
        Strangelove"</I>.</P>

Director of classic films such as "2001" and "Doctor Strangelove".

It's hard to spot things like this unless you're looking - so train your eyes to spot missing quotation marks like this!

Both these problems could have been caught earlier if you'd validated your HTML. It's a useful service, particularly if you're having problems where just can't spot the cause.

Back to the top

Image problems

1. Broken images. If you see something as on the right, with the "broken image" marker appearing (it looks slightly different in Netscape, but you'll recognise it), check that the filename specified in the SRC attribute of the <IMG> tag corresponds exactly to the filename of the image; watch out for capital letters (particularly in the extension) and remember to avoid spaces in your filenames. Note also that this image does not have an ALT attribute, which just compounds the problem.

Remember also that your HTML should not use "absolute links": see the examples below. You may find these sneaking in if you use Dreamweaver or other editors to write your code, but that's no excuse - always check your code for these things, and remove them!

WRONG! <IMG SRC="M:/www/image.jpg">

RIGHT! <IMG SRC="image.jpg">

2. Blank lines in multipart images. This is a really frustrating little problem and the solution seems utterly illogical, but it's the only one I've been able to see. It's worth a try! Compare these two images (in the original version of this image each section was a link, but I've removed link tags for clarity). Note that in Opera they will both look OK, but that's because Opera is a better browser than Internet Explorer!

If you view the source code for this page you can see the difference between the two tables (I have included comments at the appropriate point - scroll down until you see them). There is no difference in the actual code. The only difference is that the code for the right-hand table is all run together, with no spaces anywhere between the tags. This should, in theory, make no difference at all to how the page is rendered on screen - but it does. The browser must gather up some of the spaces in the code and treat them as text. If your multipart image has these spaces in it, ditch the neatly indented code and go with the confusing run-together method! (Note also that HTML editors, such as Dreamweaver, may also produce code which generates the blank lines - you will probably have to edit it manually.)

Back to the top

Link problems

1. Links work on the local machine but not when the site is uploaded; or they don't work at all. More than likely this is a similar problem to the "broken image": use of an "absolute" rather than a "relative" link, which in this case, means a link that has included a drive letter, directory structure or the like. I've said it before and I'll say it again:

Put all your site's files (including images) in the same directory...
then ensure your links are "clean" of anything other than the filename:
<A HREF="nextfile.html"> is RIGHT,
<A HREF="M:nextfile.html"> or <A HREF="/www/nextfile.html"> is WRONG!.
OK?

Seriously, do watch out for this, especially as HTML editors can sometimes sneak these things in without your noticing. They can also be inserted if you Save your page from within the browser instead of from within Notepad - never do this!! It's the first thing to look for.

If still in doubt, ask yourself the even more obvious question - does the file exist at all? Did you upload it? It's quite easy to make a spelling error in your HREF attribute, so what should be a link pointing to nextfile.html is in fact pointing to nxtfile.html; which of course doesn't exist. Even more tricky to spot, sometimes, is a confusion between the .html and .htm extensions, which is why I strongly suggest you are consistent with which one you use. Make your choice, and stick to it.

2. Links which should open in a specified second browser window keep opening new ones; or vice versa. Remember that computers are not that clever. They can't spot missing underscore characters; so, to the idiot genius that is the computer, target="_blank" and target="blank" are two entirely different things. The first will open a new browser window that has no name; every target="_blank" the browser comes across will have the same effect, in other words, you will end up with a profusion of new windows. On the other hand, target="blank" - without the underscore - will indeed open a new browser window the first time it is encountered, but it will call that window "blank". Ergo, every subsequent target="blank" attribute will be taken by the computer to be referring to the browser window called "blank" rather than a brand new window.

Similarly, if you make a spelling mistake in what you think is a reference to an already-existing browser window, the computer won't differentiate; it'll think you want to open a new browser window, with this brand new (misspelt) name. So, for instance, although all the references to the sample site should open in the same browser window - named, sample, this link will, if you try it, open in an entirely new window, because of the mistake in the code:


      <A HREF="sampindex.html" target="smple">this link</A>

Another example of the need to be precise in HTML, and one which can cause much exasperation.

3. Anchor links just return you to the top of the page or don't work at all. Again this is probably down to a typing error (so many of these problems are!). If you mistype either the name of the anchor link itself (<A name="...">) or the reference to it in the <A HREF="#...."> tag, the browser will react in one of the two ways specified; either return you to the top of the page, or ignore the link altogether. Other common explanations for this are that you've simply forgotten to insert the <A name="..."> tag altogether (something I am constantly guilty of, even after some years designing web pages...) or that you've forgotten the hashmark (#) in the <A HREF="..."> part of the link.

Back to the top

Other problems

1. Style sheet definitions are not being reflected in the site. There are several reasons why this might be the case. The first is, simply, that browsers are not always able to handle them. That is why you were warned, when dealing with style sheets, to keep in mind that they are a developing web design technology. For instance, un-tiled background images cannot be properly positioned within Netscape. That's just the way it is!

More tricky is when a technique that you know should work does not, or the whole style sheet seems to fail. If the latter is the case the first thing to check is that the <LINK> tag is present and correct: that it points to the correct style sheet file, that there are no missing quotation marks, and that the other, more obscure attributes are in place.

Then check that you've remembered not to include the angle brackets in your tag names. The series of definitions within a style sheet for a paragraph tag should be prefixed by P, not by <P>. Check that curly brackets { } are correctly in place at the beginning and end of the list of definitions. Check that each definition ends with a semi-colon. As a reminder, a defintion for a complete tag might look like this:


h1  {  color: #006600;
       background-color: #ffffff;
       font-family: Garamond, Times New Roman, serif;
       font-size: 24pt;
       font-weight: bold;  }

Even if that's all OK there can still be some little niggles getting the browser to recognise the sheet. If you make changes to a style sheet they will not always be reflected upon pressing Refresh (or Reload). Sometimes it is necessary to actually re-open the page from scratch.

Finally remember that some properties are inherited from others. The best way to think about this is to remember that every piece of style information is defined somewhere, even if only in the browser default. Text colour, font, size; background colours or images; table widths; anything else you might think of, it's all been defined either in the browser default, style sheets or attributes. (The exceptions, remember, are information that is purely structural, such as ALT attributes, or the destinations of links.) Tags that inherit information from other tags can of course change that information; but if you don't change it, you will inherit as below.

The following are the general rules of inheritance:

Every tag inherits from the <BODY> tag.
Every tag inherits from a tag it is nested within (for instance, a <LI> tag from a <UL> tag, or an <A> tag if, as it should be, it's included within a <P> tag). <TR> tags inherit from <TABLE> tags, and <TD> tags from both upper table levels.
A sub-class of a tag will inherit from the main definition of that tag; say if you have a p.emphasis class defined in your style sheet, that inherits from the main <P> definition.
A:hover inherits from the other pseudo-classes of the <A> tag.
Any element with a background colour inherits that colour from whatever is "behind" the element. (Strictly this isn't due to rules of inheritance but because the default background colour is "transparent".)
Finally bear in mind that the six heading tags are not pseudo-classes of the same tag, despite looking like it. They are entirely separate tags and therefore, for example, an <H2> tag will not inherit properties off <H1>.

Material on this site is © Drew Whitworth and ACOM, 2002. Permission will usually be given to reproduce material from this site for non-commercial purposes, if credit is given. For enquiries, e-mail Drew at andrew [dot] whitworth [at] manchester [dot] ac [dot] uk.