Previously, when HTML coders wanted to cause a link to open in a new window, they used the target
parameter in their anchor tags, specifically <a target="_blank" ...>
. This, of course, is deprecated (invalid) in the current standards (HTML 4.01 Strict and XHTML 1.0 Strict). While the target
parameter apparently will return in HTML5 we are nonetheless left with the current dilemma of how to recreate this behavior.
I have noticed a small variety of popular responses, solutions, to this:
target
parameter
<a target="_blank" href="http://tyleruebele.com/">
<a onclick="window.open(this.href,'_blank');return false;" href="http://tyleruebele.com/">
rel
parameter value external
<a rel="external" href="http://tyleruebele.com/">
<script type="text/javascript"> var anchors = document.getElementsByTagName("a"); for(var i=0; i < anchors.length; i++){ if(anchors[i].getAttribute("href") && -1 < anchors[i].getAttribute("rel").indexOf("external")) { anchors[i].target='_blank'; } } </script>
Option 1 is clearly outside the intent of the standard and this article. Option 2 is compliant, and cleanly self-contained in the anchor. Option 3 attempts to replicate the simplicity of <a target="_blank" ...>
with rel="external"
, and recreate the functionality with a few lines of javascipt, typically added to the end of the document.
Okay, so enough back story, what's wrong with using rel
? Let's see what the W3C HTML spec says:
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.
Thus, rel="external"
indicates that the relationship of the specified link is external to the document/website of the link itself. By applying option 3 to this attribute, we tie two meanings together that do not always go together. For example, what if you want an internal link to open in a new window? Or, what if you want to have an external link not open in a new window? You have to then find a way to divorce the two features, that you just erroneously married.
Secondly, look at what that script is doing. It's just adding the very attribute we were trying to avoid for compliance' sake. While I have some dissonance about this issue, I try to avoid adding explicitly deprecated parameters in this manner.
Another, more subjective, reason is found in the question of how much the document (coder) should have over the users' experience: (Outside the context of web-applications, that is, in the context of standard websites) Shouldn't the user get to decide when and if to open a page in a new window? Personally, I get frustrated when a link makes the decision for me, because it both crowds my tab-bar and breaks my history chain ("Why can't I go back? Oh, close the tab"). This, "let it die" argument, though, I leave to the subjectivity of each coder.
What, then, do I suggest? You mean besides option 2? Well, if you want to maintain the convenience of option 3, but the distinction between external links and pop-up links, consider rel="popup"
or class="popup"
as options that (while still somewhat unsemantic) don't step on existing features or concepts.