This is a legacy document, and retained on the site in order to avoid link rot. The content is likely no longer (a) accurate, (b) representative of the views and philosophies of current site management, or (c) up to date.
The following question came up once in the ciwas news group in relation to an experienced problem on how to properly use URI's in an external stylesheet so that the browsers would understand how to find the resource, even when its located locally on the same system.
My answer to this addresses how to set up relative URI's to be used both on the server as well as locally, and also gives info in regards to the "nasty" URI bug that is in the Netscape 4.0x series of browsers.
First: the question
I tried to include for background-image a local file to display,
but neither Opera or Netscape both don't do it. As explained in
the spec for a URI:
What would the syntax be for a local file? I tried to do the same
thing except for substituting something like
Perhaps I should use something like
Then: the answer
First item to consider may is that unless you are running your
own HTTP server locally to access your pages, an absolute URI can
not be made to work on your system. An absolute URI in one of its
forms, starts with…
That very first part
(http:) specifies that the
resource pointed to by the URI should be recovered by the use of
Hyper Text Transfer Protocol
HTTP server software, e.g. Apache , are known to return data while using that protocol, a direct hard disk access on the other hand does not use any established URI protocol at all, so some kind of mapping is required for this to work on a local system as well as through a WWW server. This is where the concept of a "relative URI" comes in, more about that later.
Second item to consider may be that support may be better
implemented for the shorthand form of background inclusion so it
might be better to write…
…but that's still a reference to an absolute URI of course.
In it's absolute simplest form you could write it like
…and that will "work" _if_ your HTML doc, your stylesheet file and your image.gif are all in the same directory on your hard drive.
Now for the tricky part. To cover up for a bug in Netscape one has to be careful about how files are located in directories, if they are kept in different places on your HD. The CSS specs says that…
Any relative URI found in a stylesheet file shall be resolved, starting from the location of that file.
…so let's say you have a directory structure like this…
/dir0//dir1/your-html-doc.html /dir2/your-css-file.css /dir3/your-image.gif
…now the correct URI to put in the stylesheet
…and this now means "move up one level from dir2 (from where the stylesheet file is) and then one level down into dir3 to find the file image.gif" (the double dots means move one level up to the parent directory)
And this works just great in all browsers but Netscape. The bug in NS is that it starts to resolve the URI from the location of the HTML file instead, so for NS the sequence would be "move up one level from dir1 (where the HTML file is) and then one level down into /dir3 from /dir0 to find the file image.gif", but there is no /dir3 available one level down from /dir0 right? so NS will never find the background image.
The only method available to make relative URI's work cross browsers (including NS) is to keep all files at the same directory level if you want to have them in different directories, like this.
For this dir structure it does not matter if you start from /dir2 or /dir1 you will still find /dir3 following the same line of reasoning.
There's no reason to think about HD search paths, like your
All browsers are programmed to work by URI notations, and to resolve URI's properly into local HD paths whenever that is called for. Think of it as the base URI is already set to…
…when the browser opens the HTML and stylesheet files, so it's working only by relative references from there.