background image

[Erik Schulp]

Hi all,

I am using a background image via a stylsheet.

I've used this code: background-image:url("/images/tile.gif"); (which
I think is correct)

The image doesn't show up however, the path, the filename etc etc,
everything checks out ok.

Anybody an idea what might cause this ?
Erik Schulp
www.sgtclog.nl
[e-mail]

-Let's all hope there is intelligent life on other planets,
cuz' here on earth, there is bugger all!- *Monty Python*

[Analysis&Solutions]

In <34********************************@4ax.com> Erik Schulp <es*****@NOSPAM-home.nl> writes:

I've used this code: background-image:url("/images/tile.gif");

Ditch the quotes. Maybe add a space between "image:" and "url." The
following works for me:

background-image: url(http://localhost/rickshaw/graphics/logoback.gif);

--Dan

--
FREE scripts that make web and database programming easier
http://www.analysisandsolutions.com/software/
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
4015 7th Ave #4AJ, Brooklyn NY v: 718-854-0335 f: 718-854-0409

[Christoph Paeper]

*Erik Schulp* <es*****@NOSPAM-home.nl>:

background-image:url("/images/tile.gif");

That's correct syntax. To tell you more than that one needs to see more of
the code (CSS and probably HTML also), better yet give the URL and in which
browser[s] the image doesn't show up.

--
The Hitchhiker's Guide to the Galaxy: "To summarize: It is a well-known fact
that those people who must want to rule people are, ipso facto, those least
suited to do it. To summarize the summary: Anyone capable of getting themselves
made President should by no means be allowed to do the job. To summarize the
summary of the summary: People are a problem."

[Philipp Lenssen]

Christoph Paeper wrote:

*Erik Schulp* <es*****@NOSPAM-home.nl>:

background-image:url("/images/tile.gif");

That's correct syntax. To tell you more than that one needs to see
more of the code (CSS and probably HTML also), better yet give the
URL and in which browser[s] the image doesn't show up.

Without any other context than above; quotations around URLs in CSS,
though correct, can confuse some browsers.

--
Google Blogoscoped
http://blog.outer-court.com

[Tim]

On Thu, 18 Sep 2003 15:19:25 +0200,
Erik Schulp <es*****@NOSPAM-home.nl> wrote:

I've used this code: background-image:url("/images/tile.gif"); (which
I think is correct)
Do you mean something like:

body
{
background-image: url("/example.gif");
}

We don't know if you're trying it somewhere fancy that doesn't work, or
in the wrong way, or with a browser that doesn't support it.
The image doesn't show up however, the path, the filename etc etc,
everything checks out ok.

Anybody an idea what might cause this ?

Only with an example. There's too many variables in the equation.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

[Grayle]

In article <34********************************@4ax.com>, eschulp@NOSPAM-
home.nl says...

Hi all,

I am using a background image via a stylsheet.

I've used this code: background-image:url("/images/tile.gif"); (which
I think is correct)

The image doesn't show up however, the path, the filename etc etc,
everything checks out ok.

Anybody an idea what might cause this ?
Erik Schulp
www.sgtclog.nl
[e-mail]

body {background: #dadada url("./images/tile.gif") }

Note the . before the / No doubt someone will will say that it is not
necessary, but try it. It's how I always do it, and it works here. I've
heard the quotes are optional.
Don't forget that path/filename is case sensitive if your site is on a
*nix server.

--
Win98se, P200 MMX, 64MB RAM Opera7.20b11

[Tina Holmboe]

Grayle <tt*****@ubgxrl.arg.nh> exclaimed in <MP************************@news.hotkey.net.au>:

[quoting Eric Schulp]

I've used this code: background-image:url("/images/tile.gif"); (which
I think is correct)

body {background: #dadada url("./images/tile.gif") }

Don't forget that path/filename is case sensitive if your site is on a
*nix server.

Oh, yes, filenames and paths are indeed case insensitive on Unix-family
computers, but the above is not a path - it's an URI. To boot, his URI

/images/tile.gif

points to a difference resource than your URI

./images/tile.gif

The syntax quoted:

background-image:url("/images/tile.gif");

is correct, if slightly compact and IMHO bad style. However, without
more information the only thing I can suggest is to remember that for
CSS stylesheets the base URI is that of the stylesheet, not that of
the document.

I doubt that matters here. We need more information.

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905

[Chris Morris]

ti**@greytower.net (Tina Holmboe) writes:

background-image:url("/images/tile.gif");

is correct, if slightly compact and IMHO bad style. However, without
more information the only thing I can suggest is to remember that for
CSS stylesheets the base URI is that of the stylesheet, not that of
the document.
Except in Netscape 4, of course - yet another bug.
I doubt that matters here.

Given the leading /, only if the CSS file is on a different host:port
combination to the page.
with mixed http and https pages.

--
Chris

[Grayle]

In article <34********************************@4ax.com>, eschulp@NOSPAM-
home.nl says...

Hi all,

I am using a background image via a stylsheet.

I've used this code: background-image:url("/images/tile.gif"); (which
I think is correct)

Mikko's excellent post led me to actually have another look at this.

For good measure, we'll add three more cases, where the images are in
the root directory along with the HTML and the CSS.
One: url(tile.gif)
two: url(/tile.gif)
three: url(./tile.gif)
In an OFF-LINE environment ...
Opera7.2b11 and NN4.08 treat all six cases (ie; the first three plus
(images/tile.gif), (/images/tile.gif) and (./images/tile.gif)
identically and always displays the image called "tile.gif" in the sub-
directory called "images"
NONE of IE5.0, Mozilla/Firebird, Opera6.05, Opera7.02 and KMeleon0.7
display the image for case two/five, but they treat cases one/four and
three/six as identical and display the image correctly.

So - Nikolaos was mostly wrong when he suggested

background-image: url(/images/tile.gif)
NOTE: The lack of double quotes

because it only works in NN4 and a (possibly broken) beta of Opera, and
I was half-wrong when I suggested

(./images/tile.gif)

because although it works, it's unnecessary. (so Nikolaos was right
about that)

Mikko was correct when he said that (images ...) and (./images ...) were
functionally equal. Thanks Mikko - I can save two bytes every time I
point to something! I LIKE that.

Scores to date: Mikko 10 Grayle 5 Nikolaos 5
Now let us shift the CSS file into a subdirectory (say, /css), leaving
the HTML in
root and the images in /images.
For good measure, we'll add as case seven, (../images/tile.gif), which
is the only one that ought to work.

IE5, Moz/Firebird, Kmeleon, Opera6.05, Opera 7.02 and Opera7.2b11 find
the image if it
is addressed (../images/tile.gif) but not, as expected, in any other
case.
NN4.08 finds the image in cases one, three, four and six (NOT when
correctly addressed as above)
Remember all of the above are OFFLINE findings on MY machine.

Aaah buggerit. Go here -
http://www.hotkey.net.au/~ggboyle/wip/dottest.htm
and
http://www.hotkey.net.au/~ggboyle/wip/dottestdir.htm

--
Win98se, P200 MMX, 64MB RAM Opera7.20b11

[Nikolaos Giannopoulos]

Grayle wrote:

In article <34********************************@4ax.com>, eschulp@NOSPAM-
home.nl says...

Hi all,

I am using a background image via a stylsheet.

I've used this code: background-image:url("/images/tile.gif"); (which
I think is correct)

Mikko's excellent post led me to actually have another look at this.

For good measure, we'll add three more cases, where the images are in
the root directory along with the HTML and the CSS.
One: url(tile.gif)
two: url(/tile.gif)
three: url(./tile.gif)

If you want to talk cases then post URLs for each of your cases
otherwise as I said before please don't make mis-leading suggestions
unless you can back them up.

Post URLs and then we can all look at what you are talking about.

In an OFF-LINE environment ...
Right. And the reason for this is so that *nobody* can verify your
claims - In an offline environment anyone can claim anything.

This is already looking like its going to be a great rebuttle.

Opera7.2b11 and NN4.08 treat all six cases (ie; the first three plus
(images/tile.gif), (/images/tile.gif) and (./images/tile.gif)
identically and always displays the image called "tile.gif" in the sub-
directory called "images"
I think you are really missing the point here - the OP has *never* given
enough information to correctly determine what his problem is. He only
gave reference to a CSS rule with an absolute URL.

Where his CSS rule lies - within the html document or in an external
stylesheet in some folder is all speculation.

Since he does not give this information then we can't help him further
other than to suggest possible issues NOT related to location.

Christoph Paeper wrote: That's correct syntax. To tell you more than that one needs
to see more of the code (CSS and probably HTML also), better
yet give the URL and in which browser[s] the image doesn't show up.
As Tim wrote: We don't know if you're trying it somewhere fancy that doesn't work,
or in the wrong way, or with a browser that doesn't support it.
As Tina wrote: However, without more information the only thing I can suggest is
to remember that for CSS stylesheets the base URI is that of the
stylesheet, not that of the document.

I doubt that matters here. We need more information. ^^^^^^^^^^^^^^^^^^^^^^^^^
Are you getting the picture here....

Thus there are no cases at least none that the OP has provided and
really not much to talk about unless the OP wants to give further info.

If you want to start a new thread on what "your" cases then go ahead but
don't expect many replies unless you provide *online* URLs.

NONE of IE5.0, Mozilla/Firebird, Opera6.05, Opera7.02 and KMeleon0.7
display the image for case two/five, but they treat cases one/four and
three/six as identical and display the image correctly.

So - Nikolaos was mostly wrong when he suggested
Mostly wrong???? How do you determine that AND moreover about what.
Take a look at this URL:

http://www.solmar.ca/temp6/index.html

whose CSS is here:

http://www.solmar.ca/temp6/css/base.css

Do you see the lack of double quotes - Do you see the images.

Yes this works in IE 5 and IE 6 win, Opera 6.05 and Moz 1.3. Therefore
I have no idea what you are talking about. If the quotes are required I
would be happy to include them if someone can tell me what browsers it
does not work in - and yes I would like to see it for myself in an
ONLINE environment.

If you need to (a) put "./" in front of URLs to make things work for you
and you can (b) only provide test cases in an offline environment then I
think there may be something wrong with your system configuration.

background-image: url(/images/tile.gif)
NOTE: The lack of double quotes

because it only works in NN4 and a (possibly broken) beta of Opera, and
I was half-wrong when I suggested

(./images/tile.gif)
Half wrong. Most people with any real world CSS *hide* their CSS from
NN4 and really who cares if it works for a beta version of Opera (of
which you fail to mention a version for to boot).

How about totally wrong - and totally useless.

because although it works, it's unnecessary. (so Nikolaos was right
about that)

Mikko was correct when he said that (images ...) and (./images ...) were
functionally equal. Thanks Mikko - I can save two bytes every time I
point to something! I LIKE that.

Scores to date: Mikko 10 Grayle 5 Nikolaos 5
Scores??? For what - Hey Mikko your beating us ;-) At least I'm tied
with Grayle.... Wow. Where is the competition???? What's the prize????

Honestly, I asked you to provide online test cases and the only thing
you could do was reply to the OP with *non-tangible* test cases -

You may be right that things don't work without double quotes in an
offline environment but I honestly don't care to even try if you won't.

Now let us shift the CSS file into a subdirectory (say, /css), leaving
the HTML in root and the images in /images.

[snip]

Got tired of reading your cases that you don't have the courtesy to
provide a URL for....

Scores to date:

Mikko Doesn't matter Grayle *unknown* Nikolaos Doesn't matter

If you want to broaden your understanding then go ahead - if you want to
turn posts into a competition then please grow up.

--Nikolaos

[Brian]

Nikolaos Giannopoulos wrote:

http://www.solmar.ca/temp6/index.html

http://www.solmar.ca/temp6/css/base.css

Do you see the lack of double quotes - Do you see the images.

Yes this works in IE 5 and IE 6 win, Opera 6.05 and Moz 1.3. [snip] If the quotes are required I would be happy to include them if
someone can tell me what browsers it does not work in

On the contrary! While quotes are allowed by the spec, MSIE/Mac 5.1
(IIRC) chokes on them. 5.0 can handle them. Strange, that. In
response to a request for testing help, I tried different things out
while housesitting for a prof who had a Mac, and posted my findings here.

http://groups.google.com/groups?&thr...news.dfncis.de

(url may wrap in your newsreader)

The results are now available on the web:

http://w3development.de/css/assigning_external_css/

--
Brian
follow the directions in my address to email me

[Nikolaos Giannopoulos]

Brian wrote:

Nikolaos Giannopoulos wrote:

http://www.solmar.ca/temp6/index.html
http://www.solmar.ca/temp6/css/base.css

If the quotes are required I would be happy to include them if
someone can tell me what browsers it does not work in

On the contrary! While quotes are allowed by the spec, MSIE/Mac 5.1
(IIRC) chokes on them.

Right.

I don't use quotes to wrap URL's in CSS - as can be seen on the site
which I deliberately referenced. I had heard that some browsers had
problems when quotes were present but did not know of the specific
browsers (thanks for the info on IE 5 Mac).

My original suggestion was the following to which Grayle replied:

Grayle wrote: So - Nikolaos was mostly wrong when he suggested

background-image: url(/images/tile.gif)
NOTE: The lack of double quotes

I simply gave him an *online* example where no quotes are utilized and
the background image works on *at least* IE 5 and 6 on win, Mozilla 1.3
and Opera 6.05.

In my response to Grayle (top), I left open the fact that if there is a
browser that has a problem with the *lack of* (not presence of) quotes
then I would love to hear about it otherwise I don't think quotes should
be used.

--Nikolaos

[Grayle]

In article <XR********************@magma.ca>, ni******@solmar.ca says...

If you want to talk cases then post URLs for each of your cases
otherwise as I said before please don't make mis-leading suggestions
unless you can back them up.

Post URLs and then we can all look at what you are talking about.
What part of

Aaah buggerit. Go here -
http://www.hotkey.net.au/~ggboyle/wip/dottest.htm
and
http://www.hotkey.net.au/~ggboyle/wip/dottestdir.htm

do you not understand? <snip>
I think you are really missing the point here - the OP has *never* given
enough information to correctly determine what his problem is. He only
gave reference to a CSS rule with an absolute URL.
not missing anything. I made the same assumption in my original post as
it appears you did in yours.
Where his CSS rule lies - within the html document or in an external
stylesheet in some folder is all speculation.

Since he does not give this information then we can't help him further
other than to suggest possible issues NOT related to location.

correct.

--
Win98se, P200 MMX, 64MB RAM Opera7.20b13

[Nikolaos Giannopoulos]

Grayle wrote:

In article <XR********************@magma.ca>, ni******@solmar.ca says...

http://www.hotkey.net.au/~ggboyle/wip/dottest.htm
You make the following statement on your test page:

"HTML and CSS are in root,..."

Herein I believe lies your mis-understanding - the root of your web
server is not the directory that this html page is found in (which
specifically is):

http://www.hotkey.net.au/~ggboyle/wip/dottest.htm

*BUT* instead the root of your web server (account) is:

http://www.hotkey.net.au/~ggboyle
A "/" at the start of a URL makes the URL absolute i.e. relative to the
root directory of your web server i.e. in your case relative to:

http://www.hotkey.net.au/~ggboyle

IMPORTANT: Absolute URLs don't make sense in an offline environment as
there is no root web server directory on your offline file system i.e.
you can only test absolute URLs when your pages are running inside a web
server. Some people specifically install web servers on their local
machines just for this reason.

Moreover a "./" at the start of a URL makes the URL relative which is
EXACTLY the same as if it where not present.
To be clear:

..conone and .conthree use relative URLs to locate the resource:
http://www.hotkey.net.au/~ggboyle/wip/goat.gif

..contwo uses an ABSOLUTE URL to locate the resource:
http://www.hotkey.net.au/~ggboyle/goat.gif
*BUT* goat.gif does not exist in the directory
http://www.hotkey.net.au/~ggboyle so this case won't work. Put goat.gif
in there and this will work.

..confour and .consix are similar to .conone and .conthree (except for
the added subdir) and work as they locate the resource:
http://www.hotkey.net.au/~ggboyle/wip/dot2/grakat.gif

..confive is similar to .contwo and does not work since it once again
tries to locate a resource (using an absolute URL) that does not exist:
http://www.hotkey.net.au/~ggboyle/dot2/grakat.gif

http://www.hotkey.net.au/~ggboyle/wip/dottestdir.htm

Once again you make the following mis-statement:

"HTML file is in root. CSS is in /css2..."

Html and CSS respectively are in:
http://www.hotkey.net.au/~ggboyle/wip/dottestdir.htm
http://www.hotkey.net.au/~ggboyle/wi...testdotdir.css

NOT in the following root dirs that you are suggesting:
http://www.hotkey.net.au/~ggboyle/dottestdir.htm
http://www.hotkey.net.au/~ggboyle/css2/testdotdir.css

More cases to go through...

IMPORTANT: The main thing to remember with external style sheets is that
relative URLs are determined FROM the external stylesheet NOT the HTML file

..conone and .conthree use relative URLs to obtain resource at:
http://www.hotkey.net.au/~ggboyle/wip/css/goat.gif
*BUT* goat.gif does not exist in the css dir

..contwo uses a absolute URL to access the same resource as .contwo in
your *first* test page i.e. the resource at:
http://www.hotkey.net.au/~ggboyle/goat.gif
*BUT* we already know that doesn't exist from the first test page

..confour and .consix are similar to .conone and .conthree (except for
the added dot2 subdir) and try to locate:
http://www.hotkey.net.au/~ggboyle/wi...ot2/grakat.gif
*BUT* once again goat.gif does not exist in the css/dot2 subdir

..confive uses an absolute URL to access the same resource as .confive in
your *first* test page i.e. the resource at:
http://www.hotkey.net.au/~ggboyle/dot2/grakat.gif
*BUT* we already know that doesn't exist from the first test page

..conseven unsurprisingly works as it tries to access a relative URL
(starting from the CSS dir) located at:

http://www.hotkey.net.au/~ggboyle/wi...ot2/grakat.gif

which is the same as:

http://www.hotkey.net.au/~ggboyle/wip/dot2/grakat.gif

and thus makes the NET effect of case .conseven equivalent to the result
found in .confour and .consix on your first test page.

I think you are really missing the point here - the OP has *never* given
enough information to correctly determine what his problem is. He only
gave reference to a CSS rule with an absolute URL.

not missing anything. I made the same assumption in my original post as
it appears you did in yours.

Yes - we both made an assumption but we both made very different
assumptions.

You made the assumption that absolute URLs don't work - no doubt I can
see now why since they would not work in an offline environment without
a web server and you probably didn't realize this - until hopefully now.

The URL the OP presented was absolute:

/images/tile.gif

and you suggested that he try:

../images/tile.gif

which is a relative URL.

If his CSS rule was in a file (HTML or external style sheet) in the root
directory of his web server then your suggestion at best would have made
no difference - at worst your suggestion causes additional confusion
especially when coupled with a comment such as:

"No doubt someone will will say that it is not necessary, but try it."

My assumption was that the user knows something about URLs - in fact you
kind of need to know, not just for CSS but for HTML as well - being a
CSS forum my suggestion was to remove the double quotes as others have
pointed out that that causes problems in IE 5 mac.

Where his CSS rule lies - within the html document or in an external
stylesheet in some folder is all speculation.

Since he does not give this information then we can't help him further
other than to suggest possible issues NOT related to location.

correct.

Hopefully you'll now understand a little more about why people don't
recommend the "./" prefix to URLs and moreover the difference of
absolute vs. relative URLs coupled with why absolute URLs don't work in
an offline environment.

Finally, in order for all your test cases to work these are the
addtional files that you need to have - I'll specify them as absolute
resource URLs:

/goat.gif
/dot2/grakat.gif
/wip/css/goat.gif
/wip/css/dot2/grakat.gif

Put goat.gif and grakat.gif in these locations and things will work
(online of course).

If you don't believe what I am saying then take a look at your test
pages (which are unaltered) at:

http://www.solmar.ca/ggboyle/wip/dottest.htm
http://www.solmar.ca/ggboyle/wip/dottestdir.htm

My apologies for the length of the reply but I honestly hope this clears
things up for you.

Still think I was "mostly wrong"? ;-)

I spent significant time putting this together for you - hopefully you
will take something away from this discussion that will help you down
the road.

--Nikolaos

[kchayka]

Nikolaos Giannopoulos wrote:

Grayle wrote:

In article <XR********************@magma.ca>, ni******@solmar.ca says...

http://www.hotkey.net.au/~ggboyle/wip/dottest.htm

You make the following statement on your test page:

"HTML and CSS are in root,..."

Herein I believe lies your mis-understanding - the root of your web
server is not the directory that this html page is found in (which
specifically is):

http://www.hotkey.net.au/~ggboyle/wip/dottest.htm

*BUT* instead the root of your web server (account) is:

http://www.hotkey.net.au/~ggboyle

For non-virtual domains like this, unless there's some redirection going
on root is at the domain level, not the account level. So an absolute
URL of "/path/file.ext" is looking for
"http://www.hotkey.net.au/path/file.ext".

If you're going to use absolute URLs in cases like this, refer to root
as "/~ggboyle/".

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

[Tim]

On Wed, 24 Sep 2003 13:06:28 -0400,
Nikolaos Giannopoulos <ni******@solmar.ca> wrote:

You make the following statement on your test page:

"HTML and CSS are in root,..."

Herein I believe lies your mis-understanding - the root of your web
server is not the directory that this html page is found in (which
specifically is):

http://www.hotkey.net.au/~ggboyle/wip/dottest.htm

*BUT* instead the root of your web server (account) is:

http://www.hotkey.net.au/~ggboyle
A "/" at the start of a URL makes the URL absolute i.e. relative to the
root directory of your web server i.e. in your case relative to:

http://www.hotkey.net.au/~ggboyle

For an address such as that, the root is <http://www.hotkey.net.au/>,
not <http://www.hotkey.net.au/~ggboyle/>.

Using a resource relative to the root directory, would be whatever the
webserver's root directory is.

e.g. Stored in /var/www/html/ on a Linux system.

If the ggboyle user wanted to refer to the root space of their own
userspace, that's a different thing again.

e.g. Stored in /home/ggboyle/public_html on a Linux system.

i.e. No correlation.

If you wanted to use a consistent (*) absolute address for something in
the webserver's root directory, you'd use the normal root path.

e.g. href="/something.css"

If you wanted to use a consistent absolute address for something in the
user's own space, then you'd use the user's root directory.

e.g. href="/~ggoboyle/something.css"

By consistent, I mean that if you didn't want to work out what the
different relative addresses would be for something, depending on how
many generations it's away from the parent, so every page could use the
same address, no matter where it was currently located.

e.g. /~ggboyle/a/page/here.html and /~ggboyle/another/page.html could
refer to something.css as ../../something.css and ../something.css
respectively, using relative addresses. Or both would use
/~ggboyle/something.css if using absolute addresses.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

[Nikolaos Giannopoulos]

Tim wrote:

On Wed, 24 Sep 2003 13:06:28 -0400,
Nikolaos Giannopoulos <ni******@solmar.ca> wrote:

A "/" at the start of a URL makes the URL absolute i.e. relative to the
root directory of your web server i.e. in your case relative to:

http://www.hotkey.net.au/~ggboyle
For an address such as that, the root is <http://www.hotkey.net.au/>,
not <http://www.hotkey.net.au/~ggboyle/>.

That's not how I understand virtual accounts and I assume that the
common practice of prefixing a user name with a ~ implies that it is a
virtual account.

If ggboyle is in fact a virtual account (as it seems - another indicator
is that the root server account is that of an ISP's) then the document
root for ~ggboyle should - if configured properly - be:

http://www.hotkey.net.au/~ggboyle/

Notice that I said:
*BUT* instead the root of your web server (account) is: ^^^^^^^
NOT "the root of the web server is:"

If ggboyle is a virtual account and the ISP has configured the root to
be http://www.hotkey.net.au/ then I consider the account to be
mis-configured as it makes no sense to have a virtual account whose
document root is the root of the web server itself. That it can be done
or may be the case is obviously a possibility - that it makes any sense
is not IMO.

If ggboyle was not a virtual account then you are correct but following
the naming convention it appears to be.

Using a resource relative to the root directory, would be whatever the
webserver's root directory is.

e.g. Stored in /var/www/html/ on a Linux system.
Not if ggboyle was a virtual account - at least not on a properly
configured server. Honestly most ISP servers carry thousands of
accounts - do you honestly beleive that it make any sense that absolute
URL's of all user's would require the prefix:

/~<user_name> where <user_name> is their account name

Once again IFF the account is virtual; that it can be done or is the
case on a non-properly configured server is not in dispute - that it is
always the case is disputable IMO; especially if the server is properly
configured.

If the ggboyle user wanted to refer to the root space of their own
userspace, that's a different thing again.

e.g. Stored in /home/ggboyle/public_html on a Linux system.

i.e. No correlation.

If you wanted to use a consistent (*) absolute address for something in
the webserver's root directory, you'd use the normal root path.

e.g. href="/something.css"

If you wanted to use a consistent absolute address for something in the
user's own space, then you'd use the user's root directory.

e.g. href="/~ggoboyle/something.css"

I disagree as this is not consistent if ggboyle is a virtual account and
the account is properly configured then this would have the net effect
of looking for the resource:

http://www.hotkey.net.au/~ggboyle/~g.../something.css

Bottom line it all depends on your server configuration if its a virtual
account. I imagine chances are high that if you are paying for a
virtual account that things will be configured properly so as to not
require this prefix. If it's a FREE account then I imagine you get what
you pay for and you may be stuck requiring it.

If ggboyle is not a virtual account then you are correct wherein you
suggest that a /~ggboyle/ prefix is required.

--Nikolaos

[Nikolaos Giannopoulos]

kchayka wrote:

Nikolaos Giannopoulos wrote:

Grayle wrote:
http://www.hotkey.net.au/~ggboyle

For non-virtual domains like this,...

I'm curious what makes you believe that this is a non-virtual account?

From what I know the ~ prefix is a common indicator of virtual
accounts. That it has the ~ prefix and may not be virtual is possible
but not the brightest use of this common practice IMO.

unless there's some redirection going
on root is at the domain level, not the account level.
We can all assume one way or the other I guess - especially if the
account is virtual and it is not properly configured.

So an absolute
URL of "/path/file.ext" is looking for
"http://www.hotkey.net.au/path/file.ext".

If you're going to use absolute URLs in cases like this, refer to root
as "/~ggboyle/".

What is "cases like this"? The users account may be virtual or not and
configured properly or not. A leading "/" for a resource indicates an
absolute URL - what that true root document folder is depends on the
users account and moreover the servers configuration.

My assumption was that it is a virtual account - due to the leading ~
and that the account was configured properly - in which case this prefix
would not be necessary.

Either way it depends on the users account to know for sure.

--Nikolaos

[Grayle]

In article <rY********************@magma.ca>, ni******@solmar.ca says...

Grayle wrote:

In article <XR********************@magma.ca>, ni******@solmar.ca says...

You make the following statement on your test page:

"HTML and CSS are in root,..."

Herein I believe lies your mis-understanding - the root of your web
server is not the directory that this html page is found in ...

AHA! You're absolutely right. Thanks very much for taking the time
and effort for the detailed explanation.

--
Win98se, P200 MMX, 64MB RAM, Opera7.20

[Tim]

Nikolaos Giannopoulos <ni******@solmar.ca> wrote:

A "/" at the start of a URL makes the URL absolute i.e. relative to the
root directory of your web server i.e. in your case relative to:

http://www.hotkey.net.au/~ggboyle

Tim wrote:
For an address such as that, the root is <http://www.hotkey.net.au/>,
not <http://www.hotkey.net.au/~ggboyle/>.

Nikolaos Giannopoulos <ni******@solmar.ca> wrote:

That's not how I understand virtual accounts and I assume that the
common practice of prefixing a user name with a ~ implies that it is a
virtual account.

If ggboyle is in fact a virtual account (as it seems - another indicator
is that the root server account is that of an ISP's) then the document
root for ~ggboyle should - if configured properly - be:

http://www.hotkey.net.au/~ggboyle/

Notice that I said:

*BUT* instead the root of your web server (account) is: ^^^^^^^
NOT "the root of the web server is:"

If ggboyle is a virtual account and the ISP has configured the root to
be http://www.hotkey.net.au/ then I consider the account to be
mis-configured as it makes no sense to have a virtual account whose
document root is the root of the web server itself. That it can be done
or may be the case is obviously a possibility - that it makes any sense
is not IMO.

You're understanding is wrong. The filing system and accounts have no
particular association with each other. And no matter what account is
being referred to the "root" is the root of the server. The slash means
the root of the server, and nothing else. The following describes the
same situation in a number of ways, one of them ought to jump out and
demonstrate it for you.
If ggboyle was not a virtual account then you are correct but following
the naming convention it appears to be.
Simple test, to prove the point:

Visit <http://www.hotkey.net.au/~ggboyle/> and
<http://www.hotkey.net.au/>, they're different pages, served from
different locations.

If a page, anywhere on that service referred to /something.css as a
address, it'd be referring to the document root directory in
<http://www.hotkey.net.au/>. That's how the browser constructs a
fully-qualified address, from a partial address, using the information
that it has to hand (the current location and the hostname).

It doesn't matter about the accounts, the addresses are relative to the
hostname in the URI. If the ggboyle user wanted to refer to a document
in their document root, they'd have to prefix the address with
/~ggboyle/.

Virtual accounts don't have to be prefixed with a ~ either, that's just
a convention (a problematic one, too - it used to be forbidden character
in URIs, and isn't easy to type on all keyboards, either). But it'd be
the same either way (an address starting with a slash, starting from the
server root, followed by a subdirectory name).
Using a resource relative to the root directory, would be whatever the
webserver's root directory is.

e.g. Stored in /var/www/html/ on a Linux system. Not if ggboyle was a virtual account - at least not on a properly
configured server. Honestly most ISP servers carry thousands of
accounts - do you honestly believe that it make any sense that absolute
URL's of all user's would require the prefix:

/~<user_name> where <user_name> is their account name
They do (most users get addresses wrong, they don't understand absolute
addresses, frequently have filepaths referring to their hard drives, and
usually use relative addresses or fully-qualified addresses). ;-)

Try it and see. Convert the following example to any server where you
have more than one account, and can actually try this.

Lets say that we have users called fred, barney and wilma on an example
service. They have homespace like this:

http://example.com/~fred/
http://example.com/~barney/
http://example.com/~wilma/

In each homespace, make two files one.html and two.html. In each of
them put links *like* this:

<a href="/one.html">root one</a>
<a href="/two.html">root two</a>

<a href="/~fred/one.html">fred one</a>
<a href="/~fred/two.html">fred two</a>

(Interpolate for the other accounts.)

To further understand how absolute and relative URIs work, add some
subdirectories like this:

/into/
/into/the/
/into/the/account/

And work out how to refer to an image in the root of the user's space
relatively and absolutely.

e.g. put image.jpg into the root of fred.

All of fred's pages can refer to it as /~fred/image.jpg no matter how
deep the pages are nested. If using relative addresses, they each have
to prefix a couple of dots to go back one parent directory.

/into/test.html could use /~fred/image.jpg or ../image.jpg
/into/the/ could use /~fred/image.jpg or ../../image.jpg
/into/the/account/ could use /~fred/image.jpg or ../../../image.jpg

Any other user on example.com (e.g. barney or wilma) could refer to
/~fred/image.jpg too (just like that).

Now try using /image.jpg on any user's webpage, and watch it fail. For
a user to refer to anything in their own space, with an absolute
address, they have to supply an absolute internet address (with their
username after the root).
If the ggboyle user wanted to refer to the root space of their own
userspace, that's a different thing again.

e.g. Stored in /home/ggboyle/public_html on a Linux system.

i.e. No correlation.

If you wanted to use a consistent (*) absolute address for something in
the webserver's root directory, you'd use the normal root path.

e.g. href="/something.css"

If you wanted to use a consistent absolute address for something in the
user's own space, then you'd use the user's root directory.

e.g. href="/~ggoboyle/something.css"

I disagree as this is not consistent if ggboyle is a virtual account and
the account is properly configured then this would have the net effect
of looking for the resource:

http://www.hotkey.net.au/~ggboyle/~g.../something.css

No it would not. The address starts off with a *slash*, that means the
root directory of the *server*. That's an absolute address, *nothing*
other than the hostaddress prefixes it. It's followed by a ~ggboyle,
which is a sub-directory from the root, for all intents and purposes (as
far as URIs are concerned, the filing system structure is irrelevant).

If it hadn't started off with a slash, then the address in the href
would have been relative to the current location, and would only have
worked if you were already at the server's root directory.

It doesn't matter, at all, how the server is configured. Addresses in
pages are relative to the current page, or absolute with respect to the
server hostname. Addresses in pages are worked out from the internet
addresses (outside), which have nothing to do with the internal
arrangement of some server.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

[Nikolaos Giannopoulos]

Tim wrote:

Nikolaos Giannopoulos <ni******@solmar.ca> wrote:

The slash means the root of the server, and nothing else.

After having discussed this topic with my ISP on two occassions during
the course of this thread I obtained info for some free space (that I
don't use - we have a commercial VWS account) and tried Grayle's example
to see for myself:

http://www.magma.ca/~solmarhs/wip/dottest.htm

You are right - my sincere apologies.

Now it seems I need to have a chat with my ISP... and moreover the two
tech support people that I previously talked to ;-)

Thanks,

--Nikolaos

[Tim]

Tim wrote:

The slash means the root of the server, and nothing else.

Nikolaos Giannopoulos <ni******@solmar.ca> wrote:
After having discussed this topic with my ISP on two occasions during
the course of this thread I obtained info for some free space (that I
don't use - we have a commercial VWS account) and tried Grayle's example
to see for myself:

http://www.magma.ca/~solmarhs/wip/dottest.htm

You are right - my sincere apologies.

Now it seems I need to have a chat with my ISP... and moreover the two
tech support people that I previously talked to ;-)

It is something that isn't always well explained, and is much easier to
explain in person (well, it takes a lot of typing, to do it otherwise).
It is a technical thing, and many people just aren't technically minded,
or interested (yet they've decided to play with technical things like
computers and websites).

It's something that a lot of ISPs manage to stuff up, too. For
instance, I wasn't originally aware that my ISP had two ways to get to
our homepages, like <http://homepages.example.com.au/username/> and
<http://www.example.com.au/homepages/username/>. They managed to stuff
up the settings for the first one, the one that they wanted you to use
(it often didn't resolve to an IP, so people couldn't connect). So I
advertised the second one.

Given two wildly different schemes, you couldn't use absolute
addressing, without causing problems. And the two schemes cause caching
problems, etc.

ISP "technical support" staff is a misnomer. I've only once used an ISP
where the staff were technical, knew what they were doing, and didn't
pretend that faults with the ISP were at your own end.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

[Nikolaos Giannopoulos]

Tim wrote:

Nikolaos Giannopoulos <ni******@solmar.ca> wrote:

It is something that isn't always well explained, and is much easier to
explain in person (well, it takes a lot of typing, to do it otherwise).
The best thing actually would have been an example. I don't use free
web space only commercial space and the same goes for our clients so
this simply put - has never come up.

It makes more sense though as these free user spaces are obviously not
virtual accounts at all but simply folders on a single web server - and
that's important for the ISP I imagine - only one web server to manage
for all those thousands of free accounts on a single box.

It is a technical thing, and many people just aren't technically minded,
or interested (yet they've decided to play with technical things like
computers and websites).
It wasn't the technical aspect that was the problem - it was the fact
that these free spaces are just folders and nothing more. On a true VWS
each virtual server creates its own virtual root and there is no
problem. Where there is any problem URL re-writing can take care of
things most of the time.

It's something that a lot of ISPs manage to stuff up, too. For
instance, I wasn't originally aware that my ISP had two ways to get to
our homepages, like <http://homepages.example.com.au/username/> and
<http://www.example.com.au/homepages/username/>.
I knew about this but I never use it as we have a commercial VWS and as
such we simply use our domain name - solmar.ca. In addition, in the
past when we had our VWS on other servers and before a DNS transfer was
complete we would typically have to use a URL with a username in it to
access and test our new site (until the transfer completed). With our
last move we were simply given an IP address so I wasn't able to test
what we were discussing without having asked for the username URL.

But I found it easier to simply test all of this out on our high speed
account free web space - as it would be more like any other user space.

They managed to stuff
up the settings for the first one, the one that they wanted you to use
(it often didn't resolve to an IP, so people couldn't connect). So I
advertised the second one.
I imagine it was free and unfortunately you at times get what you pay
for ;-)

Given two wildly different schemes, you couldn't use absolute
addressing, without causing problems. And the two schemes cause caching
problems, etc.
I can just imagine - actually I would rather not.... ;-)

ISP "technical support" staff is a misnomer. I've only once used an ISP
where the staff were technical, knew what they were doing, and didn't
pretend that faults with the ISP were at your own end.

Actually our current ISP is totally awesome and typically the staff is
quite technical. Their systems are very reliable and they are very
business oriented although they are not the cheapest.

I imagine part of the problem is that I contacted their commercial tech
support and they are used to working with commercial VWS's. In any
event not a big deal in my book. Now, the other ISPs that I have had I
can write a book on.... ;-)

--Nikolaos

[Tim]

Tim wrote:

It is something that isn't always well explained, and is much easier to
explain in person (well, it takes a lot of typing, to do it otherwise).

Nikolaos Giannopoulos <ni******@solmar.ca> wrote:
The best thing actually would have been an example. I don't use free
web space only commercial space and the same goes for our clients so
this simply put - has never come up.

It makes more sense though as these free user spaces are obviously not
virtual accounts at all but simply folders on a single web server - and
that's important for the ISP I imagine - only one web server to manage
for all those thousands of free accounts on a single box.

If (by virtual web servers) you mean webserver addressing like
<http://different-usernames.example.com/>, or where you can use your own
domain name pointed at one of their own servers with a unique IP for
yourself, then yes, that's far easier to deal with (for various
different reasons), and with cases like that the root directory for the
address does refer to the root of the user's own space. For the same
reasons as I mentioned before: Not the server configuration, but the
hostname in the URI.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.