Rookie image linking question

This is my first post so I will also introduce myself. My name is Jon and I am trying to build a personal site, mainly with how-to's of some things I have done. Really just something to mess around with as I wouldn't mind getting more into web development.

I have a good book on html/css design and have done some tutorials. However, my biggest problem is with image linking / storage. I want to have A LOT of pictures since they are great for how to's.

So on my webserver, I want to have a seperate pics/ directory and within that, maybe howtos/ then maybe /watergarden and /oilchange. I may also have a /howtohtml folder with all the actual page code and text I will have.

I know there are a few ways to do this, but there is always a best way :thumbsup:

I read about how you can go back directories by using /../ but that seems childish. Couldn't I just do something like <img src="/pics/howtos/watergarden/hose.jpg"> , something at the beginning that will tell it to start at root?

Another way I thought about doing it, which if it is just as efficient, I would like to use. Possibly adding some kind of gallery tool to my server, and gallerizing all the images, then simply do <img src="http://www.mysite.com/gallery/howtos/watergarden/hose.jpg">.

Thanks guys

Depending upon the situation, it can be either just a matter of preference or a necessary coding style.

For static pages (and directories) I prefer the site-root relative version you posted - <img src="/pics/howtos/watergarden/hose.jpg">. With that, I don't need to worry about "forcing" the www or other extraneous servername info. The browser fills it in.

Where you might run in to problems with that, though, is using a more complicated system (like a CMS) where pages are generated dynamically. If my images are part of a component/module or theme, then my code can't "know" the images' site-root relative position easily. In this case, the directory relative location is the easier way to code it - <img src="../../watergarden/hose.jpg">.

Others will provide better descriptions and perhaps reasons for each of these, I'm sure.

With the ../../watergarden technique, won't it fail to produce a picture if I move the html file down one directory level, thus making it search the wrong location?


Also - I like working with "/pics/..........." since it will work regardless of where I move my html file, so long as the image stays stationary. Howevery, if I work from my local disk to develop the html, I would need to have all my html files in the same location as /pics, right? Because when it is on my webserver it knows to go back to the root and then look for pics, but on the local disk it will start in the directory it is in, correct?

Is there any loss in efficiency / speed if I do it <img src="http://www.mysite.com/pics/howtos/watergarden/hose.jpg"> ? So long as my html files and images are on the same server?

thanks

With the ../../watergarden technique, won't it fail to produce a picture if I move the html file down one directory level, thus making it search the wrong location?

Yes. But if you're moving page files around the directory structure, you'll also be breaking links elsewhere.


Also - I like working with "/pics/..........." since it will work regardless of where I move my html file, so long as the image stays stationary. Howevery, if I work from my local disk to develop the html, I would need to have all my html files in the same location as /pics, right? Because when it is on my webserver it knows to go back to the root and then look for pics, but on the local disk it will start in the directory it is in, correct?

No - the server (assuming Apache) knows how to serve up the files by the given path. If you're not testing on a local server, I don't know. I haven't tried working like that.

Is there any loss in efficiency / speed if I do it <img src="http://www.mysite.com/pics/howtos/watergarden/hose.jpg"> ? So long as my html files and images are on the same server?

No benefit that I know of. The requests are all going to the same location anyway.

Thank you for the replies Tom.