homepage Welcome to WebmasterWorld Guest from 54.196.195.158
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 35 message thread spans 2 pages: 35 ( [1] 2 > >     
The <base> element and how to use it effectively
Angonasec




msg:3412781
 3:17 pm on Aug 3, 2007 (gmt 0)

System: The following messages were split from the Metatag Labyrinth thread [webmasterworld.com]


<base href="http://www.example.com/">

to establish the base url of the site.

Our site uses internal a href links like this:

<a href="/page1.htm">

Rather than the full url.

We used to use a base ref on each page that was:

<base href="http://www.example.com/">

But recently decided to specify the exact url of each page in the base ref:

<base href="http://www.example.com/page2.htm">

So every page has a different base ref url.

Is this okay or will it cause confusion or conflict to some bots?

I did have a look at WebmasterWorld but couldn't get a definite answer.

If it's wrong we'll change it back.

[edited by: encyclo at 11:24 pm (utc) on Aug. 5, 2007]

 

pp46




msg:3413569
 12:27 pm on Aug 4, 2007 (gmt 0)

But recently decided to specify the exact url of each page in the base ref:
<base href="http://www.example.com/page2.htm">
So every page has a different base ref url

This is the way I do it, when I am scared of getting my pages hijacked.. IMO its the correct way,
(Not the same as identifier URL) which I just use on the index page with the main URL.

Correct me somebody if I am wrong please!

[edited by: encyclo at 9:13 pm (utc) on Aug. 5, 2007]
[edit reason] fixed quote tag [/edit]

pageoneresults




msg:3413585
 1:58 pm on Aug 4, 2007 (gmt 0)

Let's talk about the Base Element and how I perceive the guidelines for its use.

12.4 Path information: the BASE element
[w3.org...]

When present, the BASE element must appear in the HEAD section of an HTML document, before any element that refers to an external source. The path information specified by the BASE element only affects URIs in the document where the element appears.

I'm going to jump around a bit with this one as the above is one of the most important facets of using the Base Element. This is probably the single biggest mistake I see being made when this element is being used. Many don't know that it must be the first external file reference. If it is not, it is negated (I think). I've never used the Base Element due to other issues I'm going to spell out below.

The path information specified by the BASE element only affects URIs in the document where the element appears.

This means that the Base Element must be included on every single page and must be before any other external file reference.

This example from the W3 has always confused me somewhat. And, since I don't use Base Elements, it is of no concern anymore.

For example, given the following BASE declaration and A declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Our Products</TITLE>
<BASE href="http://www.example.com/products/intro.html">
</HEAD>

<BODY>
<P>Have you seen our <A href="../cages/birds.gif">Bird Cages</A>?
</BODY>
</HTML>

the relative URI "../cages/birds.gif" would resolve to:

http://www.example.com/cages/birds.gif

I look at the above and even now, I still don't understand why they would use an example like that, it confuses me. Yes, I know, I'm easily confused. ;) The Base Element for me would be http://www.example.com/ which the above resolves to. But why use the /products/intro.html in the Base Element? Why not just trim it back to http://www.example.com/?

The Cons of Using Base Elements

So you have this page that contains all relative URI references and one Base Element in the <head></head>. Your <head> is probably going to be stripped by a good scraper and replaced with their own, that negates the whole Base Element thing. And yes, I know, its just as easy to do a find and replace on the absolute URIs but I don't see that happening with many scrapers. They'll append relative URIs and won't touch the absolutes. Lazy.

The W3 shows a good example in their "Resolving relative URIs"...

By default, the base URI is that of the current document. Not all HTML documents have a base URI (e.g., a valid HTML document may appear in an email and may not be designated by a URI). Such HTML documents are considered erroneous if they contain relative URIs and rely on a default base URI.

Hehehe, probably one of the biggest mistakes I see made in email campaigns, or used to anyway. Copying and pasting content that has relative URIs and not making them absolute before sending. Anything relative is now open for interpretation.

Personally, I wouldn't touch the Base Element. But, that opinion comes from not fully understanding its use and why I would want to use it over my current method of using absolute URIs. I feel my level of protection from hijacking is much higher than the use of the Base Element.

On a side note, the Base Element appears to cause some issues when used with server side technology.

There is also an IE6 Bug with the Base Element. You can't select text (easily) on a page that uses the Base Element. I thought this Bug was only related to using AP (Absolute Positioning) but it is not.

And, as I now have found out, when a base element is used in a document containing text in floated elements, a IE bug that causes text to become more or less impossible to select is triggered.

[edited by: pageoneresults at 2:42 pm (utc) on Aug. 4, 2007]

GaryK




msg:3413640
 5:15 pm on Aug 4, 2007 (gmt 0)

The only time I've found a valid use for the Base Element is on websites where the header and footer are a template for every page and some of the pages are http while others are https. Changing the Base Element on the fly fixes this problem for me. Hopefully I'm not showing my ignorance. ;)

Angonasec




msg:3413697
 6:03 pm on Aug 4, 2007 (gmt 0)

Thanks pageoneresults, it confused me too :)

What do you think about me using the full url in the base ref on each individual page, combined with internal a href="/page.htm" type links?

Would it be likely to confuse bots?

Others care to comment?

Clearly, many people are also confused by the base ref meta...

pageoneresults




msg:3414301
 7:29 pm on Aug 5, 2007 (gmt 0)

What do you think about me using the full url in the base ref on each individual page, combined with internal a href="/page.htm" type links?

Hehehe, I don't. As I mentioned above, I don't use the Base Element with the exception of framesets.

Would it be likely to confuse bots?

I don't know but it still confuses me whenever the topic comes up. :)

Others care to comment?

Please do. I'd like to see an explanation in Layman's Terms.

Clearly, many people are also confused by the base ref meta.

Absolutely. Whenever something confuses me this much, I just avoid it. Also, based on the cons of using the Base Element, I see no reason to utilize it outside of production environments.

I just did a search on WebmasterWorld and sure enough, I was able to turn up a topic from 2002 where we discussed the Base Element.

Path Information - The Base Element
<base href="http://www.domain.com/">
[webmasterworld.com...]

And another from 2006...

Relative or Absolute - Argument has Escalated
[webmasterworld.com...]

And, believe it or not, I still don't have a Layman's Terms answer so I don't use it. ;)

And neither does internetheaven...

11:39 am on June 2, 2006
Just as an update. I still have no idea which way is the right way. But I just switched to the recommended version (i.e. base tag with ../ paths) and although I don't know how crawlers are dealing with that, it certainly cleared up some javascript issues we were having with one site and Internet Explorer!

g1smd




msg:3414309
 8:01 pm on Aug 5, 2007 (gmt 0)

The base tag sets the base URL that relative links from that page will use.

It is up to the user agent to resolve http://www.domain.com/folder/ and ../whatever/somepage.html to the correct fully qualified URL.

I wouldn't chance a bot getting it wrong. I never use ../../somepage.html style URLs. I always begin with a trailing / and count from the root.

pageoneresults




msg:3414322
 8:36 pm on Aug 5, 2007 (gmt 0)

The base tag sets the base URL that relative links from that page will use.

That part I clearly understand. If I were to use the Base Element it would look like this on all pages...

<base href="http://www.example.com">

Because I would never do this...

../../file.htm

It is up to the user agent to resolve http://www.example.com/folder/ and ../whatever/somepage.html to the correct fully qualified URL.

I'm not too certain I want to leave it up to the UA to "guess" and resolve the relative paths. I don't know about you, but that just doesn't give me a warm fuzzy feeling at all. ;)

I wouldn't chance a bot getting it wrong. I never use ../../somepage.html style URLs. I always begin with a trailing / and count from the root.

Me too. And many others here follow the same practice. Which means our Base Elements would all look like this...

<base href="http://www.example.com">

Note that I did not include the trailing forward slash.

I still don't want my pages out there with relative references, that's not good. Not from my perspective. That just makes the page easier to jack.

P.S. I can share a horror story or two with you in regards to relative paths and rewrites. Imagine a bot coming into a site that has all relative references (../../). Somewhere in the indexing, something goes wrong. So now the bot is in a loop and is appending ../../../../. Oh, that was back in the days when we were testing ISAPI_Rewrite. Before we knew what we were doing. ;) Luckily it was a test site.

If something can go wrong, it will go wrong. Anytime that word "relative" comes into play, something can go wrong. When the word "absolute" comes into play, you can't go wrong. It's absolute!

g1smd




msg:3414333
 8:55 pm on Aug 5, 2007 (gmt 0)

>> I'm not too certain I want to leave it up to the UA to "guess". <<

Exactly. That's why I said...

I wouldn't chance a bot getting it wrong.

tedster




msg:3414388
 10:23 pm on Aug 5, 2007 (gmt 0)

Are people just using absolute URLs for html documents, or are they also using them for objects, images, external scripts etc.?

Angonasec




msg:3414644
 8:45 am on Aug 6, 2007 (gmt 0)

I'm loathe to use the full url for images and internal html pages for two reasons:

1) Code bloat.

2) My (NFP) domain name is also a key word phrase and if the SE count the markup in their keyword density I'd be bound to trip their filters.

So I use relative internal links and base href.

Watching my logs for the last few months, I've not noticed any bots get (any more) confused than they usually do since specifying the base href of each individual page.

It really does seem like it is time W3C revised their base href docs to clarify this issue.

PS. I don't use the "../../ method, I only use "/folder/page.htm method, so do you think I'm ok?

penders




msg:3414774
 12:33 pm on Aug 6, 2007 (gmt 0)

So I use relative internal links and base href.
:
PS. I don't use the "../../ method, I only use "/folder/page.htm method, so do you think I'm ok?

But that's an absolute ref, do you need the base element afterall?

There is also an IE6 Bug with the Base Element. You can't select text (easily) on a page that uses the Base Element. I thought this Bug was only related to using AP (Absolute Positioning) but it is not.

"And, as I now have found out, when a base element is used in a document containing text in floated elements, a IE bug that causes text to become more or less impossible to select is triggered."

Hhmmm, yes, I am encountering this problem at the moment. However, I'm not sure whether to place the blame solely on the use of the BASE element.

I have 2 very similar projects. Both use the BASE element on every page (out of necessity) and both have floated elements. However, only 1 project exhibits the problem of being unable to (easily) select text in IE6 (it's either all or nothing!). The page structure does vary slightly between the projects. However, removing the BASE element in the problematic project does resolve this issue.

Using the BASE element... "Out of necessity":

These projects use a single index.php file in the root of the website, which pulls in the actual page content contained in an HTML snippet in a 'topic' subfolder (/content/topicN/). (A custom CMS if you like.)

The topic subfolder's are self contained and also contain the images just for that topic. These images are then referenced from the HTML snippet with no path (ie. src="myimage.gif") since there doesn't need to be and it's therefore easy to maintain (independantly of the whole project).

But in order for these images to be picked up when the HTML snippet is included in the main file (in the webroot), we have to write a custom BASE element into the page, so 'it thinks' it's actually still in the sub folder. Internal links, however, are 'calculated' as being root relative / absolute.

...possibly the same reason as GaryK has given above for using the BASE element.

pageoneresults




msg:3414878
 2:52 pm on Aug 6, 2007 (gmt 0)

However, only 1 project exhibits the problem of being unable to (easily) select text in IE6 (it's either all or nothing!).

I don't have an example to test but, if its similar to the AP Bug (AP = Absolute Positioning), if you position your cursor anywhere within a block level element and Ctrl + Click, you may be able to select individual block level elements instead of "all".

You know, I've been searching WebmasterWorld since this topic started and I'm surprised at just how many topics I participated in about the Base Element. Here's another one from 2002 that deals with external file references and ends up with a question from me about using the Base Element. There were no replies after that question. ;)

External JavaScript Files
Absolute URL's
[webmasterworld.com...]

Using relative paths (../../) just adds a level of complexity that will confuse some people. No, it has finally clicked for me after participating in this topic but, I still won't use the Base Element outside of production or where absolutely necessary like framesets.

Maybe someone can convince me otherwise but I don't see where its use would assist me in my site management process.

Edouard_H




msg:3414939
 3:38 pm on Aug 6, 2007 (gmt 0)

However, only 1 project exhibits the problem of being unable to (easily) select text in IE6 (it's either all or nothing!). The page structure does vary slightly between the projects. However, removing the BASE element in the problematic project does resolve this issue.

Apparently the IE 'select text' bug is triggered in XHTML because it incorrectly expects a closing tag for the base element. A conditional comment corrects this and still leaves you with a valid document.

<base href="http://www.domain.com" /><!--[if IE]></base><![endif]-->

[edited by: Edouard_H at 3:40 pm (utc) on Aug. 6, 2007]

Fotiman




msg:3414957
 3:56 pm on Aug 6, 2007 (gmt 0)

@penders:


So I use relative internal links and base href.
:
PS. I don't use the "../../ method, I only use "/folder/page.htm method, so do you think I'm ok?

But that's an absolute ref, do you need the base element afterall?

Actually, no, that's not an absolute ref. It is actually a relative link that is relative to the root. At first glance it might seem like it's an absolute ref., but in fact it is not. If, for example, you move the page containing this link to a new site, the link is now relative to the root of the new site, not the original site (so it is clearly not absolute).

pageoneresults




msg:3415000
 5:10 pm on Aug 6, 2007 (gmt 0)

Relative Paths = src="images/file.gif", src="./images/file.gif, src="../images/file.gif, src="../../images/file.gif
Root Relative Path = src="/images/file.gif"
Absolute Path = src="http://www.example.com/images/file.gif"

The Dot Segments in a relative path can really confuse the heck out of many, including myself. Yes, I understand ./ and ../ and ../../. But, the problem comes in when you have a site that takes advantage of multiple levels. I just find using Root Relative links minimizes any issues associated with appendage which I've seen happen. Why take the chance?

So, for those following along, if you use the Base Element and have Relative Path References then you would use a Base Element of the page you are on. For example, if I'm working on http://www.example.com/sub/file.asp and I'm using relative file paths, my Base Element would be...

http://www.example.com/sub/file.asp

In a relative path environment, the Base Element will be the full path of the page you are working on. So, that means your base element is unique for each page, yuck, more maintenance.

In a root relative path environment, the Base Element will be the root domain only without the trailing forward slash...

http://www.example.com

Someone correct me if I'm wrong.

In a relative environement you have to make sure your Dot-Segments are correct through the entire site. And, you need to be sure that all editing software is configured to produce relative path references with the proper number of Dot-Segments. If that doesn't confuse the average Webmaster...

GeneVincent




msg:3415344
 10:31 pm on Aug 6, 2007 (gmt 0)

When using a Base-Href, I found that even some of the big search engine bots get confused about simple mailto: links and start treating them as regular links.

Is there a way to fix that?

Bewenched




msg:3415358
 10:54 pm on Aug 6, 2007 (gmt 0)

One problem I had with a base tag was I just put it in the header to define our main domain and didn't think about the SSL pages. Make sure you put https instead of http when using them on a secure page or it will throw errors in browsers.

theBear




msg:3415513
 3:58 am on Aug 7, 2007 (gmt 0)

"I'm loathe to use the full url for images and internal html pages for two reasons:

1) Code bloat.

2) My (NFP) domain name is also a key word phrase and if the SE count the markup in their keyword density I'd be bound to trip their filters."

I thought reason one went the way of the DoDo bird given that a lot of sites that are out there, even the simple ones tip the scales at support files out weighing markup, frequently by many times. One with 131KB markup and 1.6MB scripts and images comes to mind .

Happy to meet you Angonasec, I didn't know that other folks who care about such matters still existed.

I suppose reason 2 might apply if the search engines were totally brain damaged or if you have errors that cause the links to appear as actual content. Many thousands of pages latter I haven't seen any evidence of that.

[edited by: theBear at 3:59 am (utc) on Aug. 7, 2007]

wtkad




msg:3415732
 12:46 pm on Aug 7, 2007 (gmt 0)

I currently use the base element because I need the same code to work in three different places:
My computer (127.0.0.1/example/)
The test site (www.anotherdomain.com/folder/example/)
The actual site (www.example.com)
It's much easier to change the base tag for each location than to change all the links and includes every time it's moved.

But I do get 404 errors like:
www.example.com/folder/stylesheet.css
Even though the base tag should make it:
www.example.com/stylesheet.css
I don't know what user-agents those come from, and I've never seen a wrong one in Google Webmaster Tools, but it does happen. It could just be the smaller bots that no one wants anyway. But it verifies the above caution - if you're relying on being spidered perfectly, you probably shouldn't depend on the base tag.

On the next redesign, I'm planning to use a different system for code transporting myself.

penders




msg:3415762
 1:14 pm on Aug 7, 2007 (gmt 0)

Angonasec: So I use relative internal links and base href.
:
PS. I don't use the "../../ method, I only use "/folder/page.htm method, so do you think I'm ok?

But that's an absolute ref, do you need the base element afterall?

Fotiman: Actually, no, that's not an absolute ref. It is actually a relative link that is relative to the root.

Yes, thanks for the correction, I do have a habit of referring to root relative links as being absolute.

The point of my comment, however, was that root relative links don't pay any attention to the value of the BASE element, which the original poster was implying did. No need for the BASE element in this case.

penders




msg:3415816
 2:11 pm on Aug 7, 2007 (gmt 0)

Apparently the IE 'select text' bug is triggered in XHTML because it incorrectly expects a closing tag for the base element. A conditional comment corrects this and still leaves you with a valid document.

<base href="http://www.domain.com" /><!--[if IE]></base><![endif]-->

Yes, that works great, thanks. :)

However, I'm still wondering why text is still selectable in the other project without having to close the BASE element. I wonder if there is something which is effectively closing this element elsewhere in the code(?) or as pageoneresults suggests it may be in combination with the AP bug, as there is an AP element in this project, although Ctrl + Click had no effect.(?)

Angonasec




msg:3416285
 12:57 am on Aug 8, 2007 (gmt 0)

Fotiman: Actually, no, that's not an absolute ref. It is actually a relative link that is relative to the root.

Yes, thanks for the correction, I do have a habit of referring to root relative links as being absolute.

The point of my comment, however, was that root relative links don't pay any attention to the value of the BASE element, which the original poster was implying did. No need for the BASE element in this case.

I agree the terminology is confusing, I think it is better to refer to the 'full url' rather than the 'absolute url' to avoid confusion.

So, in my case, you think the use of the base href is redundant?

I added it after reading here about hijacking, and prefer belt and braces.

If it really is redundant, is it likely to confuse any bots?
(All my pages validate strict at W3C.)

thebear: I honestly believe each of the big 3 SEs are perfectly capable of counting markup in keyword density, either in error or purposely. It could explain why a lot of clean sites are suffering a drop in their listings.

pageoneresults




msg:3416428
 3:52 am on Aug 8, 2007 (gmt 0)

The point of my comment, however, was that root relative links don't pay any attention to the value of the BASE element, which the original poster was implying did. No need for the BASE element in this case.

Ah, so I was incorrect?

If you are using Root Relative links (/images/file.gif), then the use of the Base Element is negated and there is no need for it, correct?

If you are using Relative links (images/file.gif, ./images/file.gif, ../images/file.gif., etc.), then the use of the Base Element comes into play.

So now you have another unique element on each page and that is the full URI of that page which is now the base element for all relative paths. Not Root Relative but Relative.

Remember...

Relative File Path = images/file.gif, ./images/file.gif, ../images/file.gif, ../../images/file.gif
Root Relative File Path = /images/file.gif
Absolute File Path = http://www.example.com/images/file.gif

I do Root Relative for all image files, etc. I do Absolute for all internal links. Always have and probably always will. Same goes for external file references, always Absolute.

I've always preferred an Absolute environment. It leaves no room for error. At least not in my experience.

Absolute - Free from conditions, limitations or qualifications, not dependent, or modified or affected by circumstances; that is, without any condition or restrictive provisions.

penders




msg:3416528
 7:48 am on Aug 8, 2007 (gmt 0)

The point of my comment, however, was that root relative links don't pay any attention to the value of the BASE element, which the original poster was implying did. No need for the BASE element in this case.

Ah, so I was incorrect?

Well, I was perhaps a tad hasty in my comment, but if you are on the same domain then using a BASE element is unnecessary if you are using root-relative links, IMO.

If you have a BASE element set to:
<base href="http://www.example.com/sub1/sub2/index.html">

And use a root-relative path, then:
<img src="/img/myimage.gif">

Refers to:
<img src="http://www.example.com/img/myimage.gif">

Whether you'd specified the BASE element or not. So no need for the BASE element IMO.

** HOWEVER ** You could specify an entirely different domain in the BASE element, in which case your root-relative path will indeed be relative to the root of the domain specified in the BASE element.

So now you have another unique element on each page and that is the full URI of that page...

But if you set the BASE element to the URI of a different page...

I added it after reading here about hijacking, and prefer belt and braces.

How so?

Angonasec




msg:3416754
 1:03 pm on Aug 8, 2007 (gmt 0)

I added it after reading here about hijacking, and prefer belt and braces.

How so?

Well, even "if" the base href is redundant when used in conjunction with root relative internal links (like I'm doing), it hopefully will snag the casual hijacker too lazy to switch the base href url.

I find most thieves are lazy about such details.

I'm grateful for the input to this thread, we do appear to be inching towards daylight. And it might even wake up the W3C bods.

HarryM




msg:3416774
 1:23 pm on Aug 8, 2007 (gmt 0)

Using the full url avoids problems with the BASE element. But as mentioned earlier in this thread, the problem with using the full url is the difficulty of testing in a different environment.

I get around this with php. I have an include which is required on each page. I can set the environment for the whole site by commenting out the line not required.

include

<?php
$siteroot = "http://localhost:8080/";
// $siteroot = "http://domain.com/";
?>

links

All inter-page links take the form:

href="<?php print $siteroot;?>directory/file.php"

or:

href="{$siteroot}directory/file.php"

I only use this for pages, and use relative file paths for images and anything internal to php.

theBear




msg:3416788
 1:43 pm on Aug 8, 2007 (gmt 0)

"I honestly believe each of the big 3 SEs are perfectly capable of counting markup in keyword density, either in error or purposely. It could explain why a lot of clean sites are suffering a drop in their listings."

They could count a lot of things, I also have seen many clean sites suffer a drop in their rankings.

But their markup containing full links hasn't been the cause of any of them as far as I've been able to determine.

Could, would, should, and does can all be different. It just makes no sense for the search engines to do what you are postulating.

It makes far more sense to look at a myrid of other causes. Some of which have been given a lot of air time on WebmasterWorld, but really haven't been looked at from all angles.

For example:

I've never seen a complete disection of what all of the possible effects of someone causing a group of a site's pages to be indexed on another domain. Which by the way can happen on a mis configured server without any intentional acts on the part of the domain owners.

I can see several possible things that does in addition to duplicating the content.

1: It can under certain conditions duplicate a portion of the link structure ...

2: It can under certain conditions cause a large number of links to appear for the site the pages were coming from ...

Both of which may affect the original sites rankings and not just for the pages copied.

Google in particular hates the smell of link manipulation.

But that is just me, YMMV, but it is good to know that at least there is some one else out there that hates bloat. I was beginning to think the entire world had 100Mbps links to the World Wide Wobbly.

[edited by: theBear at 1:44 pm (utc) on Aug. 8, 2007]

Angonasec




msg:3417471
 12:15 am on Aug 9, 2007 (gmt 0)

thebear: But their markup containing full links hasn't been the cause of any of them as far as I've been able to determine.

Could, would, should, and does can all be different. It just makes no sense for the search engines to do what you are postulating.

If the domain name was a three-word-key phrase with hyphens, or underscores, it may well inadvertently fall foul of, say, G's recent changes in handling suchlike. etc.

Speculation, of course, but another factor to consider before using full urls in markup.

Code bloat: Actually, it was that 'orrible Alexa that prompted me. A few years ago they used to display your site's load-speed, and I was shamed by being in the lowest third.

I've been in the fastest third ever since.

Switching to all css really helped. No tables at all.

theBear




msg:3417588
 4:21 am on Aug 9, 2007 (gmt 0)

The last I knew the search engines were interested in content and mark up isn't content and in the case of Google link text which again isn't markup.

As for Alexa's load times what can I say someone has to be at the slow end.

Now css is interesting however the way it frequently gets used these days it contributes to bloat. Add a bit of javascript and you can even bring a high end system to its knees.

This 35 message thread spans 2 pages: 35 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved