New-Window Links in a Standards-Compliant World

Thats very helpful zcorpan.

Thanks very much

I don’t know. I’m using Safari 1.3 to view, and DWMX to script, and I can’t get Safari to respond to this script. I used explicit paths, moved it different directories–even put the script inline within header tags…still nothing. Any suggestions?

Tom - Check the quotation marks. I had trouble because I copied and pasted the code, but I just changed the quotations and all worked fine after that.

This script was very useful!
Thanks alot

wow, this is so helpful. no more rightclicking>open in new window :smiley:

Is there a way gain control over the attributes of the new window that is opened? For example, height, width, position, visibility of address bar, menus, scrollbars, etc.?

I can’t get this script to work at all. tom mentioned in the last comment that some of the syntax could have errors in it. is that the case or is there any other reason why it won’t work…?

cheers

whats wrong with onclick=“window.open(this.href);return false” ?

Problem with this function is on:
window.onload = externalLinks;
If you have another script using onload it won’t work. In such case, put the code at the end of your page before the last /body tag and replace last line with:
externalLinks();
You may also use a hack sugested in http://www.tek-tips.com/faqs.cfm?fid=4862

The easiest way of overcoming the “multiple onLoad events” problem (and in my opinion, the “nicest”) is creating an “init” function:

<script type=“text/javascript”>
function init() {
init_event_1();
init_event_2();
init_event_3();

}
</script>

<body onload=“init();”>

or …

use a generic function to add events to existing events on any element…

addEvent = function(elmArray,evt,fn){
for(var i=0;i<elmArray.length;i++){
if(elmArray[i].addEventListener){
elmArray[i].addEventListener(evt,fn,false);
} else if (elmArray[i].attachEvent){
elmArray[i].attachEvent(“on”+evt,fn);
} else {
el[“on” + evt] = fn;
}
}
}
addEvent(window,‘load’,externalLinks);

I still don’t really see the point of this; and it does sound a lot like “cheating” to me… Consider these points:

If it’s going to be kept within the DOM, but not within the HTML, surely this means that it’ll eventually be phased out of all such Standards-monitored areas? And in any case, I don’t really see the point of relying on JavaScript to set the target attribute of an anchor tag, when it’s been around for years – if you’re going to set it anyway, I would consider ignoring the validator warning “just this once”, for now, and using it in the first place, for the continued benefit of all browsers/“User Agents”? This will also eliminate the seemingly unnecessary additional backend.

And another things – why have you “mixed-and-matched” with regards to the getAttribute() method and its counterparts? You use it to obtain the values for “href” and “rel”, but then use anchor.target directly. I’d use this “global scope” or whatever it’s called most of the time, because I’m lazy for one thing; and for another, I don’t see why you should have to read the value of an attribute using one approach, but set it with another. There are times when element.getAttribute(name) is necessary, it seems, possibly with custom attributes and such-like, if they’re desired (grey waters surrounding that field; but I can see Peter-Paul Koch’s ideology, even if I would prefer to “kill two birds with one stone” and use className whenever I can…); but otherwise, I don’t really see a reason for following such a scheme to the letter, as such. Having mentioned className, by the way, how come element.className exists as an alias to element.getAttribute(‘class’)? And no-one seems to dispute the “special” status of the style attribute… Wouldn’t element.getAttribute(‘style’) return a string, like cssText, as opposed to an “object reference”, anyway?

Sorry for the length of this comment. It’s a good script by design, I’m just not sure of the necessity for its usage…

[If this is a duplicate entry, please delete…]

I still don’t really see the point of this; and it does sound a lot like “cheating” to me… Consider these points:

If it’s going to be kept within the DOM, but not within the HTML, surely this means that it’ll eventually be phased out of all such Standards-monitored areas? And in any case, I don’t really see the point of relying on JavaScript to set the target attribute of an anchor tag, when it’s been around for years – if you’re going to set it anyway, I would consider ignoring the validator warning “just this once”, for now, and using it in the first place, for the continued benefit of all browsers/“User Agents”? This will also eliminate the seemingly unnecessary additional backend.

And another thing – why have you “mixed-and-matched” with regards to the getAttribute() method and its counterparts? You use it to obtain the values for “href” and “rel”, but then use anchor.target directly. I’d use this “global scope” or whatever it’s called most of the time, because I’m lazy for one thing; and for another, I don’t see why you should have to read the value of an attribute using one approach, but set it with another. There are times when element.getAttribute(name) is necessary, it seems, possibly with custom attributes and such-like, if they’re desired (grey waters surrounding that field; but I can see Peter-Paul Koch’s ideology, even if I would prefer to “kill two birds with one stone” and use className whenever I can…); but otherwise, I don’t really see a reason for following such a scheme to the letter, as such. Having mentioned className, by the way, how come element.className exists as an alias to element.getAttribute(‘class’)? And no-one seems to dispute the “special” status of the style attribute… Wouldn’t element.getAttribute(‘style’) return a string, like cssText, as opposed to an “object reference”, anyway?

Sorry for the length of this comment. It’s a good script by design, I’m just not sure of the necessity for its usage…

Having read the previous posts, I like the idea of using a similar approach in order to obey the user’s preferences for opening in a new window or not: By using the “rel” attribute and then checking it via a script, you are removing the default behaviour* at first, and only telling the browser to do it if the user wants it to.

If it’s clear that it would be a “good idea” to bypass this, though, I don’t see why it would necessarily be a bad idea to just do an inline target=“_blank”; as I said. If a link opens in a new window to the general “expectation” of the majority of users, or if it is flagged in such a manner, why not?

I do like the preferences approach, though, when it would be an easy solution to implement. :slight_smile:

  • By “default behaviour”, I mean what normally happens when you put target=“_blank” inline, of course.

IFrames are a bit “better”, and XFrames actually looks “okay”, for when browsers eventually get around to supporting it…? It seems like that, at least. I’ve read a bit about the ol’ “X” idea, and it seems viable – including all the URIs for each identified frame in one “global” URL pointing to the frameset itself? I like the sound of that; it allows for bookmarks to work properly and all that, based on the status of the entire visible content. And it seems to eliminate the need for target at all – although wouldn’t changing the main URI of the page, even just to specify a different address for a single frame, cause it to refresh along with all the frames within it, which isn’t really what you want?

Anyway, I don’t really see a way around the problem of targetting conventional frames without Javascript, for instance, or using the target attribute as it was originally intended. With JS you could of course reference the window.top element and its location property, or that of a child frame if you wanted; but if I had to use frames, I’d want it to be as independant as possible. And I’d go with IFrames if I could – maybe even the <object> container tag if it was more widely supported in the “proper” sense (Firefox parses the page properly, just like an iframe, if you set the type attribute correctly… It’s pretty lonely there, though, lol). Better than the original frameset approach, at least.

I just came across the following article which explains how to continue to use the target=“_blank” option using XHTML Strict. Since this was the 2nd highest listing in google’s search, I thought it would be appropriate to link to it for a more thorough explanation.

http://www.accessify.com/tutorials/standards-compliant-new-windows.asp

lol, that might as well just be a “DTD hack” for all its awkwardness… Although at least the module is all ready-to-go, I suppose.

I’m with Abraham on this one.
Why would anyone want to remove an attribute that works so well and to my knowledge, causes no problems at all, to anyone? It’s not like the font tag or certain attributes which are much more easily taken care of else where. Removing this actually makes things harder.

I understand the point of only using XHTML to present content, with JavaScript taking care of behaviour but if you’re going to go this far surely the fact that you click on a link and are taken to a different page at all is also behaviour. I would of thought that most users expect external links to open in a new window - I thought one of the reasons behind standards was uniformity and giving users what they expect consistently. What’s the point of having a new standard if it just gets “worked-around”, nothing is achieved.

What real practical use is there for depreciating this attribute with no alternative?

This is a great technique. I like that if javascript is disabled, the links still work in the original window (far better than not at all). It also won’t get into trouble with pop-up blockers which is nice.

There is (as always) one hitch: <area> tags cannot have “rel” attributes. How then can we make areas in an image map send their links to an external browser window, all while remaining true to the XHTML Strict standard?

Certainly a challenge.

This is a great little script, but I needed to do something like this with a form to open a PayPal window, so used the following:

<form action=“ExternalURL” enctype=“foo” method=“post” class=“external”>

and the javascript to

<!–
function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName(“form”);
for (var i=0; i<anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute(“action”) &&
anchor.getAttribute(“class”) == “external”)
anchor.target = “_blank”;
}
}
window.onload = externalLinks;
//–>

Works a treat, thanks for giving me the starting point.

Cheers
Glynn

Sadly, the script didn’t work for me. Neither in FF1 nor in IE6. I found that the line window.onload = externalLinks; doesn’t work. I’m not a programmer so I don’t have a clue as to why…

What did work is adding a onload=“externalLinks();” to the body tag.

Thanks for the otherwhise great solution!