Relative Address Quirks

Relative links on the internet are those where the full domain name is not specified but instead the location of the page or file is specified relative to the current page. For example instead of specifying the absolute address to link to this page from other pages on this site I specify the relative address htmlt60.htm which assumes that the page is located in the same domain and directory as the page that the reference is on. This is fairly straight forward when everything is in the root directory of the domain but gets somewhat more involved when pages are located in sub-directories and gets even more involved when you have include files located in sub-directories - especially when they in turn reference other files that may or may not be located in the same sub-directory.

To make the explanation of how the relative references work in the most complex cases as simple and easy to follow as possible I will present an example with files in various locations and discuss how they would use relative references to access one another. Let us assume that we have the following structure: the root directory contains two pages (index.html and pageone.htm) and two sub-directories. The first sub-directory is called includes and itself contains two modules that we will call and The second directory called sales has a page within it called sales1.htm. This can be represented more visually like this:


To reference from either index.html or pageone.htm we would use includes/ The same applies to refer to includes/ To reference them from the sales1.htm page we must first move from the sales directory to its parent directory. We do this by adding ../ to the front giving us ../includes/

That is fairly straightforward. It gets a bit more complex if we imagine that index.html includes which references which then in turn provides links to pageone.htm and sales1.htm. Let's consider these one at a time.

  1. We already have the first one. index.html references using includes/
  2. is in the same directory as so we don't need to qualify the link we just use
  3. Now comes the part where things don't work quite the way you might expect. Both amd form part of the index.html page. Normally you would expect that to reference sales1.htm it would need to use ../sales/sales1.htm but the problem is that when relative addresses start with a dot they are taken relative to the location of the page instead of relative to the current file. This makes the correct relative address ./sales/sales1.htm with only one dot (indicating the current directory) instead of two (representing the parent directory).
  4. Similarly pageone.htm is referenced as ./pageone.htm.

Note that the addition of ./ to the front of the relative address makes it relative to the location of the main page file that references the include file instead of relative to the include file itself. We need to use this whenever an include file references something outside of the directory that contains it but could of course refer to files within a sub-directory of that directory relative to the include file instead of relative to the main page file.

The biggest problem occurs if we have used by both index.html and sales1.htm and we need to provide a link to pageone.htm. Relative to index.html we need ./pageone.htm but relative to sales1.htm we need ../pageone.htm. As we can't have both at the same time we either need to code mdule2.js in such a way that it determines where it was called from in order to provide alternative relative links or we need to specify the absolute address of pageone.htm instead.

Note that the above does not apply with external javascripts and stylesheets. With javascripts which always run client side the addresses are always relative to the directory containing the main page. With stylesheets the reverse is true and addresses are always relative to the stylesheet and not to the page that contains them. If in doubt make sure that you test your page properly to make sure that all of the modules are found and links work correctly.


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow