 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / September 2003background image
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 eschulp@-houjerotzooimaar-home.nl -Let's all hope there is intelligent life on other planets, cuz' here on earth, there is bugger all!- *Monty Python* >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  SignatureFREE 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 *Erik Schulp* <eschulp@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. SignatureThe 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." > *Erik Schulp* <eschulp@NOSPAM-home.nl>: > > [quoted text clipped - 3 lines] > 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. SignatureGoogle Blogoscoped http://blog.outer-court.com > 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. SignatureMy "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. > 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) Try: background-image: url(/images/tile.gif) NOTE: The lack of double quotes. --Nikolaos > Hi all, > [quoted text clipped - 10 lines] > www.sgtclog.nl > eschulp@-houjerotzooimaar-home.nl 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. SignatureWin98se, P200 MMX, 64MB RAM Opera7.20b11 >>I've used this code: background-image:url("/images/tile.gif"); (which >>I think is correct) > 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 may be a completely different address. Erik's image is in an images directory in the DOCUMENT_ROOT. Your image is in an images directory in the directory where the CSS file is. SignatureJohannes Koch In te domine speravi; non confundar in aeternum. (Te Deum, 4th cent.) Grayle <ttoblyr@ubgxrl.arg.nh> exclaimed in <MPG.19d539b1f8b1c9c8989758@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. Signature- Tina Holmboe Greytower Technologies tina@greytower.net http://www.greytower.net/ [+46] 0708 557 905 > 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. SignatureChris > In article <34cjmv4ir534miee7tph71d5r21gjbk04f@4ax.com>, eschulp@NOSPAM- > home.nl says... [quoted text clipped - 3 lines] > 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. Can you provide a test page that this makes a difference for because your right about one thing there is ZERO reason to do this. If a browser needs this then I would honestly recommend ditching the browser. What the "./" means is look in the current directory on Unix systems and yes it is required if you are say a root user (on a securely set up Unix box) and you want to run something OUTSIDE the browser at the command line. That's it - that's all. Honestly since you are doing this on your site then just clone one of your pages and remove the "./" from the URI's and provide the links to both pages - I'd be amazed if I saw any issues. If you can't do this then please don't provide advice of this nature. --Nikolaos >>In article <34cjmv4ir534miee7tph71d5r21gjbk04f@4ax.com>, eschulp@NOSPAM- >>home.nl says... [quoted text clipped - 12 lines] > box) and you want to run something OUTSIDE the browser at the command > line. That's it - that's all. English isn't my native language, so perhaps Nikolaos's comment is indeed correct, but I think some clarification wouldn't hurt. Say we have a HTML page with the URL http://domain.example/foo/bar.html and it links to a stylesheet: <link rel="stylesheet" href="styles/default.css" type="text/css">. A correctly behaving browser will connect to domain.example port 80 and send "GET /foo/styles/default.css" possibly followed by " HTTP/1.1" (that is, the browser should request URL "http://domain.example/foo/styles/default.css"). If the bar.html contains tag <link href="stylesheet" href="./styles/default.css" type="text/css"> instead, the browser should generate a pseudo-URL "http://domain.example/foo/./styles/default.css" and further compute the real URL "http://domain.example/foo/styles/default.css". Notice that there is no difference whether or not a relative url has "./" prefix or not. On the other hand, if the tag had been <link href="stylesheet" href="/styles/default.css" type="text/css"> then correctly behaving browser should generate URL "http://domain.example/styles/default.css". Note that this URL is different from the example above. As a general rule, adding "/" prefix to a relative url changes where it points to. The fact that "./" happens to point to current directory in UNIX systems has nothing to do with URLs. Neither does the fact that adding "/" prefix to any path in UNIX generates an absolute path. Now, say we have a CSS style sheet at http://domain.example/foo/styles/default.css and if that style sheet contains something like { background: url(bg.png) } then a correctly behaving browser will generate URL http://domain.example/foo/styles/bg.png. Some broken browsers (like NN4.x) generate URL http://domain.example/foo/bg.png - that is, those compute relative URLs in stylesheet relative to HTML document instead of relative to the CSS document that contains the relative URL. Because of this, some guides say that every url in a CSS style sheet should start with "/". SignatureMikko >>> body {background: #dadada url("./images/tile.gif") } >>> [quoted text clipped - 12 lines] > English isn't my native language, so perhaps Nikolaos's comment is > indeed correct, but I think some clarification wouldn't hurt. Thanks for the clarification Mikko but unfortunately unless the OP provides more information your entire explanation may be for nothing. My reply was directed squarely at using "./" in a URL and that it in no way alters the resource that is selected when "./" is removed. --Nikolaos > 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 SignatureWin98se, P200 MMX, 64MB RAM Opera7.20b11 >>Hi all, >> [quoted text clipped - 10 lines] > 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) [quoted text clipped - 4 lines] > > 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 > http://www.solmar.ca/temp6/index.html > [quoted text clipped - 3 lines] > > 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?&threadm=b5cev9%24271gta%241%40ID-61067.news.dfn cis.de (url may wrap in your newsreader) The results are now available on the web: http://w3development.de/css/assigning_external_css/ SignatureBrian follow the directions in my address to email me >> http://www.solmar.ca/temp6/index.html >> http://www.solmar.ca/temp6/css/base.css [quoted text clipped - 4 lines] > 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 > 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. SignatureWin98se, P200 MMX, 64MB RAM Opera7.20b13 > 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/wip/css2/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/wip/css/dot2/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/wip/css/../dot2/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. [quoted text clipped - 3 lines] > > 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 >> http://www.hotkey.net.au/~ggboyle/wip/dottest.htm > [quoted text clipped - 11 lines] > > 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/". SignatureTo email a reply, remove (dash)un(dash). Mail sent to the un address is considered spam and automatically deleted. >>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 > You make the following statement on your test page: > [quoted text clipped - 14 lines] > > 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. SignatureMy "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. >>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: [quoted text clipped - 3 lines] > 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. [quoted text clipped - 12 lines] > > 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/~ggoboyle/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 >>> 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/>. > 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 [quoted text clipped - 18 lines] > 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. [quoted text clipped - 12 lines] >> >> 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/~ggoboyle/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. SignatureMy "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. > > 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 wrote: >> The slash means the root of the server, and nothing else. Nikolaos Giannopoulos <nikolaos@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 [quoted text clipped - 7 lines] > 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. SignatureMy "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 <nikolaos@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 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 [quoted text clipped - 4 lines] > 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. SignatureMy "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. > 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. SignatureWin98se, P200 MMX, 64MB RAM, Opera7.20 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.