This is an article discussion thread for discussing the SitePoint article, “New-Window Links in a Standards-Compliant World”
Really helpful - thanks!
This seems like a reasonable approach to a problem that is definitely causing confusion to developers. My concern though is that if “target” is being phased out of XHTML, why would it be available in the DOM? It might be legible for now, but I can see the target object in the DOM being phased out too to match the XHTML standards.
Thanks for a useful tutorial anyway!
I agree with bigsi on this one. However for the time being it is an excellent solution to the problem. We can only hope CSS3 implements target:self,top,parent,blank etc.
I was pointed to this article right after posting a question in the forums, actually my qustion was equivalent to this article’s title.
In answer to bigsi:
If XHTML is suposed to get rid of every presentation, and behaviour tags is because those tasks will be taken by CSS and JS (or similars).
In this particular case, the “target” is purely behaviour, so it remains as a Javascript task, just as “font” is now a CSS duty.
Thinking that way, I don’t see why could DOM quit supporting target, or CSS supporting font because of XHTML standards.
Agreed, it is behaviour - but what do people think about the accessibility issues surrounding the opening of new windows?
this is too much like work. it’s easier to just use something like this: http://liquidpulse.net/articles/xhtml/general/opening_new_windows_in_xhtml_strict/introduction
It’s easier to understand for non-programmers, it’s accessable, and it degrades gracefully if the user doesn’t have javascript, or has it disabled.
This is more of a better option if javascript was disabled.
<a title=“User Profile” href=“http://www.sitepoint.com/users.asp?ouid=4” onclick=“window.open(this.href, ‘popupwindow’, ‘width=400,height=300,scrollbars,resizable’); return false;”>View User Detials</a>
And if popups are disabled…?
and without js ? because that script doesn’t works in firefoz 0.93
If pop-ups are disabled it just opens in the window. And the url is still visible as a normal link.
and standards compliance is better???
What about the simple fact that I HATE it when any site opens links in new windows?
“New-window” links are evil… but sometimes they can be convenient (for showing original-sized images, or help texts, or stuff like that). For those cases, this is really helpful. The fact that the link still works when popups are being blocked is only added value.
Will this solution work even where Javascript is disabled? I am wanting to know what the best solution is where you have links within a site, such as the local weather, but you don’t want people to leave your site or have to hit their back button. I’ve always understood it to be that if you just link them away from your site, even to check weather, they might not come back. But it seems that MS new automatic security settings block all Javascript, so even my date/time js won’t work where js is disabled. Does the above solution for external links present the same problem?
Thanks!
I’d use something like that if my visitors could choose. Here is a variation on the script that looks promising. It puts a checkbox to let the user decide, then remembers their preference with a cookie.
Personally, I’d prefer that the default was not a new window, just a choice.
I tried it on a test page and for some reason it’s not working quite right when I tested it, but may be helpful for others here.
A note about the “rel” attribute used for the anchor <a>. In the w3c Rec, you could read this at link-types:
“Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types.”
Looked at the source of this page, I didn’t found profile definition in the <head profile=“”>.
To be standard, you should use this. 
P.S.: first time I heard about profiles.
Why is W3C reporting that there is no such attribute as ‘rel’ (xhtml Strict or Transitional)?
This method works very elegantly, except it won’t validate. Is there any way to make it so that it will without reverting back to html 4?
I have been using this theory for quite a few websites, but I did run into a problem. If the page is large, and/or download speeds are slow, then clicking a link will happen before the onLoad event is triggered.
I think browsers will be for a long time support target attribute.