80 comments

• RSS feed for comments on this post
• RSS feed for comments on all posts

• Jens Meiert
  February 13th, 2006 at 11:04

  New windows might definitely cause problems especially for inexperienced users. Also, the first argument (”It should be up to the end user”) is quite important. But there are exceptions, as Jakob Nielsen recently pointed out by recommending new windows for PDFs.

  When it comes to the technical solution, me, I use JavaScript (see e.g. the links to the sample chapters on my book’s microsite). Without scripts enabled, the links still work (of course), and it’s perfectly fine to have no other fallback then. It’s not critical.

  Assuming that this spec’s part gets stable some day, you will be able to use CSS 3’s target property to get rid of HTML/XHTML doctype constraints. But it will still be advisable to use new tabs/windows sparingly.

• Patek Philippe
  February 13th, 2006 at 11:11

  I’ve always thought that the third argument that it’s up to the end user wheter to open a link in a new window is totally wrong in many cases. You mensioned the PDF example, some others where i think a new tab/window is prefered is: Link collections, search results, most kind of listings (like threads in a bulletin board for example)..

• Allan Haggett
  February 13th, 2006 at 11:51

  I’ve argued this one to project managers and clients before myself and ended up loosing too. On those projects where my reasoning was ignored, I either simply held my nose and let my code be invalidated or opted for a transitional doctype which really left a bad taste in my mouth. I’d rather see an invalidation with one or two errors on a strict document than a green bar on a transitional one

  As for whether it’s really evil or not, I’d have to say that yes, the target attribute really is that bad. I don’t think that end-users are educated/experienced enough to really be execting anything at all. If they don’t know how to deal with a tab then a new window isn’t suddenly going to make sense. I think that it’s more likely that what doesn’t make sense to end-users is why their back-button is suddently broken. Studies (from what I read) consistantly show that users depend on the back button more than anything while surfing. target=”_blank” breaks the back button. For most users (the majority of whom are on windoze) the big red “X” in the upper-right means “close this program”, not “go back to that other site I was just visiting”. Especially with a Windoze UI where all windows tend to be automatically maximized, people just cannot be expected to understand what is happening.

  I think that it’s 2006. It’s time to stop coddling managers and their “expected” behaviours. They don’t really know what users expect. We might take our geekiness for granted, but I say we’re still in better touch with what end-users should “expect” (if its anything at all) than a manager who doesn’t know anything about user interface design or useability. It’s time to start steering users towards more rational behaviours that are based on actual standards and forward-thinking and not half-assed marketing intuitions based on the 1997 browsing habits of some suit who thinks that he knows about the ‘net because his business card has a .com on it.

  PS Who me? Bitter? No, I quit that job

• Tommy Olsson
  February 13th, 2006 at 12:21

  The target attribute is fine if you’re using frames.

  If not, I think you should use unobtrusive JavaScript. (X)HTML should handle structure and semantics; CSS should handle presentation; and JavaScript should handle client-side behaviour.

  To put it another way: if you think font and center elements (or even style attributes) are OK, then feel free to use target as well. If not, put it in an external, unobtrusive JavaScript file.

  IMHO, of course.

• Nick Webb
  February 13th, 2006 at 12:57

  One of the drivers behind deprecating the target attribute is accessibility. Try managing a host of popup windows when you’re using a screen reader.

  I think Allen has got a good point concerning the back button. Novice users are usually comfortable with the idea of moving between pages and then clicking back.

  Users who are more familiar with multiple windows and tabs are also more likely to be aware of the “open in new window” functionality, and will use it as they wish.

  If there is a need to open new windows, the user should be made aware of the fact that the link will open a new windowm (again, think of the screen readers). Alternatively, add two links: one to load the content into the current window, and one to open the content in a new window.

• SilentWarrior
  February 13th, 2006 at 13:08

  Most people don’t understand the behavior of tabs or new windows, and a majority get confused when they get linked to another web site in the same window/tab.

  Why do you think that? Every time my mother is surfing, she is so confused when the “green little arrow” in the navigation bar suddenly doesn’t work any longer. And I would really consider her a typical internet user.

  In the end, I went with using the target attribute. Sure, I could have used an unobtrusive JavaScript to add an onclick event and used window.open, and at the same time get perfectly valid code, but then it wouldn’t be as accessible and also dependant on scripts to function properly,

  So you think it’s better to code invalid HTML than to write a short and handy JavaScript? If you compare the percentage of visitors without JavaScript to the percentage of users on, let’s generically say, user agents which don’t support multiple windows — I would say the latter is higher (but that’s just a vague guess). Or if not, it certainly will become higher in the future (PDAs, cell phones, …).

  I agree with you in so far as I also think PDF files should not open in the same window; but instead of opening them in a new window, I would offer them for download directly. (I’m not a friend of PDF-in-browser view.)

• Robert Wellock
  February 13th, 2006 at 13:15

  I’d have chosen unobtrusive JavaScript over target for the simple reason in most user agents JavaScript can be disabled, and the link still work whereas target is another story.

• Jules
  February 13th, 2006 at 15:23

  I am of the opinion that most links should open in the same window and when they don’t, the user should be informed. As you suggest, there is a bit of a problem in that (X)HTML Strict does not allow the target attribute, even when it appears to be useful (such as PDFs) although the unobtrusive JavaScript solution is a reasonable workaround.

• zcorpan
  February 13th, 2006 at 15:51

  The bug isn’t with your web site, it’s with the PDF reader plugin. If users get lost when a PDF opens in the browser then the plugin shouldn’t do that; the plugin should be fixed. (You can change your preferences in mean time.)

  If “external links” should open in new windows then that would be the default browser behaviour. It’s reasonably easy to determinate whether a link points to an external resource or not.

  The target attribute isn’t included in Strict because it belongs to Frames.

• Robert Nyman - author
  February 13th, 2006 at 16:28

  Jens,

  I agree, if used, it should definitely be used sparingly.

  Also, regarding CSS 3, not sure if I think CSS is the correct place to put such behavior…

  Patek,

  Well, it’s a difficult question. I think it’s ok to say it’s up to the end user, given that they do understand to choose how to open it in different ways.

  Allan,

  Ah, I love a bitter tone with a glimpse in the eye!

  And I definitely agree with a strict doctype with some minor validation error compared to using a transitional one just to get it through the validator.

  Very interesting argument about the back button!

  Tommy, Robert W, Jules,

  Yes, reading the comments here I’m leaning towards the decision that I should’ve used an unobtrusive JavaScript approach instead.

  Nick,

  Yes, if the link will indeed force the user to a new window, it can be good to have that information together with the link. I’m not really sure two links would be a desirable approach…

  SilentWarrior,

  I understand about the back butto, but many people I’ve met/seen surfing has reacted like:

  Where did the web site go?

  when a link to an external web site has opened in the same window. I definitely get the dilemma, though.

  Not sure the invalid HTML code was a good option either, but then again, just one invalid attribute for such a things as this is really a minor issue to me. But as I wrote above, maybe an unobtrusive JavaScript really had been the best here…

  PDFs should definitely be in a new window, if you ask me. Like Jakob Nielsen said, people don’t understand it otherwise.

  zcorpan,

  No, it’s not about a bug or a setting, what I meant was people losing context if a PDF document opens up where the web site they were visiting just were.

  Then, regarding bugs: in my experience, opening PDF documents in a web browser has been pretty shaky, although it has gotten better lately, especially when trying to do that in Firefox.

  The target attribute isn’t included in Strict because it belongs to Frames.

  Definitely a reason, but not the only one, right?

• Steve
  February 13th, 2006 at 16:29

  Yeah, it is still a needed attribute/concept.

  If you have a site, that uses a “shared” widget, as a popup (not ads, but a real, meaningful popup), you want the popup to display, in a named window. Likewise, if the user bury’s the popup (accidental, or otherwise), rather than open a new one, it is handy to reference the old one.

  I’ve seen some horrible apps, that open dozens of calendars and such. Where targeting by name, would avoid this.

• Robert Nyman - author
  February 13th, 2006 at 16:31

  Steve,

  Yes, I’ve seen a lot of that too. But, given the discussion above, the same thing can be achieved with a properly written JavaScript too.

  Or would you say that JavaScript isn’t a good solution here?

• Robert Wellock
  February 13th, 2006 at 20:19

  Just face it you were an evildoer.

  “…I understand about the back butto[n]…”

  You did say you like people catching typo errors didn’t you?

• sculder
  February 14th, 2006 at 0:44

  The decision, I believe, is to extend the DTD. The truth is that for now, of course, DocType Definition files are ignored by browsers and even the validator returns “Invalid XHTML document, 0 errors” (very funny, don’t you find?) if you try to change it and use the structures you added in XHTML files. So, there’s no use in that. However future should change the situation, as we will get fully extensible XHTML, as promised in the conception of the language.

• Lachlan Hunt
  February 14th, 2006 at 1:29

  The target attribute is the most evil attribute in (X)HTML, it must not be used under any circumstances, least of all for PDFs!. Jakob Nielsen’s recommendation to open a new window for PDFs is, suprisingly, wrong.

  As the author, you do not know how the user’s system is configured to handle PDFs, any argument that says PDFs should open new windows are unconditionally depending upon the default (and, yes, often buggy) behaviour of Adobe PDF viewer and IE or Firefox.

  The user may have configured their viewer not to open within the browser (there’s an option in Adobe’s preferences for this, but it seems to apply within IE only, or they may not even be using the Adobe viewer). Do you really want to give such users a new blank window, while their PDF views in another application?

  The user may have the PDF Download extension in Firefox (or equivalent), or otherwise configured their browser to always save the file first. Again, do you want to give such users a new blank window?

  Avoiding it in favour of a window.open() script is no better, and those who suggest that this is somehow “unobtrusive” fail to understand the meaning of the term. An unobtrusive script is not simply one that is external from the document markup, it is one that exhibits no obtusive behaviour, and forcing a new window is one of the most obtrusive behaviours around.

  Also, the argument to use JavaScript instead of the target attribute (because JavaScript can be disabled) is flawed. Good browsers have the ability to disable the effect of the target attribute, when it would open a new window. Plus, user stylesheets can also be used to indicate the presense of the target attribute, allowing the user to take action to avoid it. In this respect, the target attribute is better than the javascript.

  Those who argue that new windows should be opened for external sites fail to realise just how many different sites a user may visit in a day. If every single one of them employed this technique for external sites, imagine how many windows the user would have if they didn’t continually close them. That, in itself, is a job the user shouldn’t be forced to do.

  The best approach to take is to inform the user what type of file you’re linking to. Let them make an informed decision about how to open it on their computer, which can meet their requirements - not yours! This applies to all file types, not just PDFs. DO NOT use the target attribute under any circumstances. It is evil! (except for within frames, but frames are evil too)

  Lastly, sculder, regarding the validator saying invalid document with 0 errors, that sometimes happens when you have the DOCTYPE incorrect. It is case-sensitive, make sure you copy and paste it correctly from this list of DTDs.

• Robert Nyman - author
  February 14th, 2006 at 9:17

  Robert W,

  Apparently I was…
  And thanks, I hate typos!

  sculder,

  I’m not sure a custom DTD would be a good option either, I’m more wondering if it’s ok under any circumstances to open a new window, than a way to get around that the HTML/XHTML is invalid.

  Lachlan,

  Thanks for a very thorough reply, and if I’m not mistaken, your first visit here (at least your first comment). So welcome.

  Very interesting opinions you share and definitely thoughtworthy. To explain the situation I was in, it was decided over my head. No extra text was allowed in the content, and it was a demand that it would open in a new window. So out with theory through the window, and just do as the people who pay say…

  Therefore, I was really after what option would be the least evil ot the poor ones I had available.

• Matthijs
  February 14th, 2006 at 22:28

  How familiar this all sounds. I think that almost 3/4 of my clients brings forward the idea to open links in new windows. Fortunately I have been able to convince almost everyone to not do that.
  I don’t know much about mobile browsing but my guess is that the many people who will browse mobile in a few years will not like all those windows.

  In the case of PDF’s opening in the SAME window, I have repeatedly seen people hit the X button thinking they are closing the DOCUMENT and actually closing their browser entirely

  Funny you say this, because I have seen the same behavior with many many (inexperienced) internet users. But they do it with EVERY window / application! Opening explorer. Closing with x. Opening outlook. Closing with x. Going back to explorer… hey were did it go? Looking for outlook. Hey were did that go? And repeating that again and again, even after I tell them “nooo! not the x!” .. but too late..

• Steve Williams
  February 15th, 2006 at 0:04

  Timely post for me, which has generated an excellent discussion and helped me out!

  I’ve certainly ‘lost’ sites by clicking the close button, thinking the link had opened in a new window… especially with pdfs. And I’ve been frustrated by sites that open new windows way too often.

  But I can also see the marketing departments point of view.

  I also have the target dilemma on a current project. The directions page has a link to Google maps, which the client and I feel has a high potential for people to roam around to such a degree that the back button is no longer a viable means to retrace back to the original site… should you wish to! So I’ve used the target attribute to open the link in a new window (other reasoning being GMaps feels more like an app than a website, and people are used to closing apps when they’re done with them).

  But having read the comments here, the js solution sounds best to me, since the sorts of devices that don’t support new windows are also unlikely to support js.

• Lachlan Hunt
  February 15th, 2006 at 1:49

  Robert, I’m surprised that was my first comment here. I’ve been reading you for a while now, but it’s impossible for me to keep track of which sites I do and don’t comment on anyway.

  since the sorts of devices that don’t support new windows are also unlikely to support js.

  Wrong. While this may be true for many browsers, it’s certainly not true for all browsers with all configurations.

  I have my Firefox configured to never, under any circumstances, open a new window or tab unless I explicity request to do so myself. This includes window.open and the target attribue, both of which just cause the the page to load in the same window, like a regular link.

  It does cause some problems with those that annoyingly use window.close due to a bug that allows scripts to close windows they didn’t actually open, but this bug has (apparently) been fixed in the trunk, which will be in Firefox some time in the future.

• Douglas Clifton
  February 15th, 2006 at 7:33

  I cannot stand sites that open new windows, and yes I have them redirected to a new tab. If I want that behavior:

  Ctrl+click
  …
  Ctrl+W

  I guess I just gave away my browser/platform combo. Of course all you’d have to do is check your logfile for my User-agent string anyway…

• Robert Nyman - author
  February 15th, 2006 at 10:01

  LadynRed, Matthijs, Steve,

  Thanks for thorough comments!

  I mean, most of us do want to open every link in the same window for a number of reasons. Then, of course, to PDF links and links to such web sites as you mention, Steve, is in a gray area, depending on what behavior one expects from one’s end users.

  Lachlan,

  I didn’t know you were!
  I wish I would’ve had the opportunity to meet you one of the times I was traveling around Australia.

  Also, thanks for contributing with the point that people have such settings in their web browsers. It just helps adding that argument to the others why links indeed should be opened in the same window.

  Douglas,

  Not really a shocker, many of my users have the same combination.
  And, to make it even, I use the same combination.

• Steve Williams
  February 15th, 2006 at 11:12

  Lachlan, your comment puzzles me a little?

  I don’t see how I’m wrong when your browser *does* support new windows *and* js? You have set your preference for browsing, which is great Granted, window.close may be a problem, but nobody has suggested its use as acceptable.

  My point is that many devices can surf the internet, but few besides regular pc browsers support js/flash/plugins etc. In most of those cases, using js to open a new window will not work, so it’s less likely to cause a problem, keeping the linked content accessible, whilst allowing the website owner their preference for how the site is experienced by the majority.

• Rowan Lewis
  February 16th, 2006 at 9:10

  <a href="#" rel="external document">?

  Or something like that…?

• Carl
  February 16th, 2006 at 15:30

  I think the evil appears when the browser (or browser configuration) allows the PDF file to be embedded in the browser with a whole new set of controls. This, as Mr. Neilsen points out, is confusing. We’ve all done it: clicked on a PDF link, viewed the document embedded in the browser then unintentionally closed the browser subconsciously thinking we were in that application, not in a web browser.

  The PDF link should open a new application window rather than embed itself into the current browser window or new browser window.

  On the other hand, if embedding is done right, then the web surfing experience can be maintained. What bothers me is when the plug-in adds a bunch of new controls, many of which duplicate the functionality of the browser. (Why does the Acrobat plug-in have a print button? Okay I want to print. Do I click that print icon or that print icon? Which one is used when I choose File:Print?)

  If the plug-in would simply show the document and provide a browser-like experience, the surfing paradigm would be maintained. Most plug-ins, however, want to impose their application’s UI paradigm on the surfer. This is where plug-ins become evil in my opinion. Okay I’ll stop ranting now. I really hope this relates somehow to the target attribute. Sorry, Robert if it doesn’t.

• Robert Nyman - author
  February 16th, 2006 at 16:16

  Rowan,

  Maybe it’s just an example, but the value for the href attribute should always be a valid URL. Your rel example sounds valid to me.

  Carl,

  No problem, I think your opinion is very valid here. The duplication of icons when viewing PDF in a web browser window is definitely confusing. Personally, I prefer when PDF links automatically opens up in “normal” Acrobat, like SilentWarrior suggests.

• Lachlan Hunt
  February 17th, 2006 at 4:10

  I wish I would’ve had the opportunity to meet you one of the times I was traveling around Australia.

  Well, sure. E-mail me or give me a call next time you’re in Sydney.

  I don’t see how I’m wrong when your browser does support new windows and js? You have set your preference for browsing, which is great…

  Because a browser that supports JS and has popups disabled is not much different from one that supports some JS but doesn’t support popups at all.

• Robert Nyman - author
  February 17th, 2006 at 9:21

  Lachlan,

  Well, it’s not like I’m there very often.
  I’ve been there twice and I hope I get the opportunity to visit your country in the future again.

• Joseph Riesen
  February 24th, 2006 at 8:58

  From my limited XHTML experience (only been using it for a year now), I’ve found writing a custom DOCTYPE to be a very workable solution for the target attribute. Irrelevant of the good or evil behind it, I’m personally used to the de facto internet standard of ‘off-site links open in new windows,’ especially when 95% of the site’s links are intra-site. The user gets used to ‘going from here to there in the application,’ and when you suddenly kick them to the other side of the internet (especially if they wander to a page that breaks the back button), they can have trouble coming back. And if it’s a really minor offsite link (e.g. ‘where to get Mozilla Firefox’) it’s all the more stupid.

  Obviously, for blogs and search engines and whatnot this would be horrible. However, in an otherwise modular web application, especially with, say, data in form fields that hasn’t necessarily been saved, I tend to go with the ’safe but annoying’ approach of using ‘target’. Also, I’ve been conditioned by the usability folks to never open new links in JavaScript if I can avoid it (even though 99% of the time my web applications require JavaScript to even get started, heh). I’ll eventually one or the other habit, but for now I’m perpetuating this fallacious interface methodology. [grin]

  Anyway, my point is that I saw a number of people talking about how the modern browsers don’t even download doctypes, and from what I can tell, this is totally incorrect. (At least if we’re talking a modern FireFox, Mozilla, or IE6.) For a specific example, check out Extending XHTML: Target and Strict, which is actually where I first learned to customize my DocType. There is absolutely no good reason to write invalid XHTML in any case; the whole point of these standards was to make browsers render consistently, and quirks mode is the surest way to end up in a flashback from the IE/NS Browser Wars. (Watching IE’s box model explode when I muck up my XHTML is always a nasty surprise.)

  Thanks for everyone’s advice. I’m definitely starting to rethink this one situation in which I actually open links in a new window. I think I’ll go for graceful degredation via JavaScript from here, at least for a while, see how it works out.

• Robert Nyman - author
  February 24th, 2006 at 10:10

  Joseph,

  Thank you very much for sharing your experiences!

• Joseph Riesen
  February 24th, 2006 at 11:25

  Sure enough, I just put my foot in my mouth.

  I was playing around with custom DOCTYPEs after posting, and it turns out that if you serve up XHTML with a custom DOCTYPE to Mozilla/FireFox… along with a Content-Type of application/xhtml+XML, things can go sour. (Or application/xml, or text/xml for that matter.) http://developer.mozilla.org/en/docs/XML_in_Mozilla is very enlightening in this regard. Apparently, when it’s in strict XML compliance mode (when it gets one of those three MIME types I mentioned above), Mozilla - and therefore Firefox - pretty much never downloads external entities (e.g. DTDs). And worse yet, it completely ignores character entities unless you’re using one of nine XHTML (or SVG) PUBLIC identifiers in the DOCTYPE declaration. I actually ran across this because Firefox barfed on   entities in my document when I tried to switch it to XHTML+XML.

  Now, you can use an internal DOCTYPE, like:

  <!DOCTYPE HTML PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/tr/xhtml11/
  DTD/xhtml11.dtd” [ <!ATTLIST a target CDATA #IMPLIED> ]>

  …which works perfectly in Mozilla/Firefox… but leaves chunks in Internet Explorer, a trailing ]> at the beginning of your page. Which tragically kicks IE back into quirks mode. (Of course, if you’re conditionally sending text/html to IE and application/xhtml+XML to Mozilla, you could also conditionally send one DOCTYPE or the other and be happy.)

  …

  I guess what I’m getting at… is that you can use a custom doctype, but no browser actually bothers to download external DTDs… and nobody really seems to care at all except the W3C validator. Both IE and Mozilla work still run in Standards mode when the MIME type is text/html if you put in XHTML Transitional 1.0, XHTML Strict 1.0, XHTML 1.1, whatever (you can check document.compatMode, honest).

  So…. what everyone said above was basically right, oops. Gonna back down and say… maybe there is a time when you go ahead and write invalid XHTML because, well, none of the browsers even care about your DTD. As for me, I’m serving up that internal DOCTYPE above in application/xhtml+XML to Mozilla/FireFox and the W3C validator (check here if you’re interested in specifics), I send my custom DOCTYPE in text/html to IE. Sure, IE doesn’t check the external DTD, but it helps me sleep easier at night.

  And I can open new windows alllll day long! [wugga wugga wugga] Take that!

• Joseph Riesen
  February 24th, 2006 at 11:27

  Oops, looks like Textile or whatever munged my link, wrapped underscores in italics. That was http://developer.mozilla.org/en/docs/XML[underscore]in[underscore]Mozilla.

  I’ll… stop posting now.

• Robert Nyman - author
  February 24th, 2006 at 12:04

  Joseph,

  Ha ha, no problem!
  Thanks for the information!

• Robert Wellock
  February 24th, 2006 at 12:19

  It’s because Mozilla and most other browsers than can deal with: “application/xhtml+XML” use only a Well-formedness Checking XML Parser and not a Validating XML Parser.

  I use custom DTD on 12 pages knowing fully well, they won’t use the DTD I wrote. They have the option to do so, actually I used it to create EMBED several years back.

• Robert Nyman - author
  February 24th, 2006 at 13:01

  Robert W,

  Good to hear that you’re on top of things!

• Brad Wright
  March 28th, 2006 at 18:46

  Sorry, I’m a little late to the party.

  Also, regarding CSS 3, not sure if I think CSS is the correct place to put such behavior…

  With regards to this, I would argue that HTML/XHTML markup is not the right place to put it either. In ye olde “Holy Triumvirate” of web standards, the DOM is the right place to put behaviour.

  This simple summary leads me to believe that taking the attribute OUT of XHTML was a well-considered move on the part of the W3C.

• peter arbuthnott
  March 28th, 2006 at 18:48

  reason 7 to NOT allow javascript to window.open and thus my continual return to transitional and target in sites I build:-
  the smallest virus in the world ever, created some time ago…
  Breaker

• Robert Nyman - author
  March 29th, 2006 at 8:33

  Brad,

  Better late than never, right?

  I definitely agree that the DOM is the place to put it, if we compare the options of having it in the HTML or CSS. My pondering with this post is that a DOM approach won’t work for people with JavaScript disabled and if we think it should do that or not.

  Peter,

  It’s a valid point but the the built-in popub blockers that most web browsers have on by default nowadays, the problem isn’t as big as before.

• Daniel
  March 29th, 2006 at 21:22

  I think the W3C went a little too far with deprecating the target attribute. Sure, the user should decide whether he wants a new tab/window but I think there are some cases where you want the user to stay on your site and only open a second one.

• lokin
  March 30th, 2006 at 2:49

  I understand the reason and thought in regards to the W3C’s standpoint on this issue. However, I actually disagree with it completely. There are many different situations that call for a new page to be opened and the choice should be up to the developer and the client not the W3C. If a designer has taken the time to learn web standards, then not only does he have an understanding of web standards, but he is also capable of making a sound decision based on the task at hand.

  For an example, I recently designed a website for a school project that promotes a musician/band. There are two links that must open a new window. One is a flash music player and the second page is a lyrics page. For the lyrics page, the navigation is identical in appearance to the main site with the exception that the links are now the song titles and only navigate the user to the various songs listed on that page. It’s clear to see why it would be important to have these links open in new windows.

  When I reached that step in the design process I was faced with two choices. I could either use Javascript and achieve strict validation, or I could just use the target attribute and not worry about it actually validating. (in the end the code would actually be strict web standards just with exception of that tag in two places.)

  In the end I decided to use Javascript and retain the reward of placing a X-HTML compliant link on the site.

  Upon reflection, a few thoughts come to mind. If the W3C’s arguement is that it should be up to the user not the designer, then why is my site able to achieve strict validation by using javascript to open new windows? After all, the web site still opens these two links in a new windows! (This seems to be a bit of an oxymoron to me.)

  Secondly, as a result of wanting to achieve strict validation as well as opening a new window, I had to resort to the use of javascript. Using javascript is not always a safe bet because I don’t know how it will work for every “end user”. Which means that these two links (flash jukebox and lyrics) may not work in every browser or for every user. So in the end it seems that I have only achieved the label of “strict validation” and made the site less accessible and functional to many users by doing so.

  To quote a definition provided by Google of what is web standards -

  “Formulated by the W3 organization, these standards enable people to create websites that will work in almost any browser or internet-enabled device”

  Ultimately, I think the choice is up to us and the project at hand. If we use the target attribute, the rest of the code is still W3C compliant. The only loss would be that you dont get to put the groovy tag on your site that proves it (since you would fail validation). The best judgement call on a situation like this would be to review and research the advantages and disadvanteges of both. Then you are able to make a sound and practical call based on the project.

• Robert Nyman - author
  March 30th, 2006 at 9:51

  Daniel,

  Yes, and that’s the interesting part of this: how far should W3C’s reach go and is it ok to stray from the rules sometimes?

  lokin,

  Thans for a long and interesting comment!

  If a designer has taken the time to learn web standards, then not only does he have an understanding of web standards, but he is also capable
  of making a sound decision based on the task at hand.

  I agree, but my take is that most web developers don’t take the time to learn to do their job properly. Therefore, a strict validation is a way for W3C to force them to adhere to validation rules, because they can, in a simple and tough way, see if their web site is correct or not.

• limalimon.com.es » El atributo target
  April 4th, 2006 at 14:23

  […] o está permitido el uso del atributo target. He estado leyendo un par de artículos [1], [ […]

• On The Topic of Hyperlinks
  April 26th, 2006 at 15:14

  […] pening new windows might make sense). Robert Nyman presents an interesting summary in this blog post from February ‘06. In Nyman’s […]

• Christopher Parker
  May 2nd, 2006 at 21:20

  What’s wrong with…

  <a href=”http://cparker15.com/” onclick=”window.open(this.href); return false; “>My Web Site</a>

  ?

  This way, you can write perfectly valid XHTML, and at the same time open a new window. If someone has JavaScript disabled, or if they’re using an old version of Lynx or something, then there’s no problem! target was meant for frames and iframes. The improper usage of target breaks the user’s back button. And even though browsers today don’t actually use custom DTDs, what’s to say they won’t tomorrow? Why set yourself up for trouble? Why misuse technology?

• Leandro Vieira Pinho - Desenvolvimento web em geral. » Blog Archive » Atributo target ou obstrusivo javascript para abrir novas janelas?
  May 3rd, 2006 at 16:14

  […] rget Blank (português); Using javascript instead of target to open new windows (inglês); How evil is the target attribute? (inglês); Nota: as argumentações de […]

• Giles
  June 9th, 2006 at 22:31

  This is a very interesting thread especially since this limitation is new to me (I have been using transitional up until now). I should point out that I am very much a pragmatist in this subject rather than a purist.

  The thing that strikes me about the comments above (particularly Lachlan Hunt’s) is that frequently the ineptitude of the average user is used as an argument _not_ to use this attribute: don’t confuse the user with a new window! But that clearly works both ways - a new site suddenly replacing everything else is also confusing.

  Surely it’s in the web designer’s interest to use new windows when appropriate - where it fits with the flow of the site and in particular where content forks. My line of thought is that this would lead to less confusion than the alternative, which is a disassociation from the original site’s content (take for example an external link from the middle of a news article - or a help page linked to from a long half-filled-in form). In these instances, a new window does not destroy your “saved state” if you will.

  All that said, the topic is still a new one to me and there’s plenty of space to change my mind as the variety of devices proliferate and I come to terms with different modes of navigation. My browsing habits currently use new windows heavily and it’s always seemed pretty efficient to me

• Robert Nyman - author
  June 9th, 2006 at 23:04

  Giles,

  Thanks for your input!

  My browsing habits currently use new windows heavily and it’s always seemed pretty efficient to me

  I can say that my web browsing habits consists of new tabs all the time (using Firefox). And there’s nothing wrong with that, but I think there’s a vast difference if you as a user choose to open a link in a new window/tab by holding down a certain key and clicking (or similiar behavior), as opposed to a web site forcing a new window upon you when you actually wanted to open it in a tab or maybe to replace the current content in the same window where the link you initially clicked was.

• Brett Brewer
  July 6th, 2006 at 22:30

  There are many cases when the average developer and user would prefer that a page open in a new window. PDFs are one obvious example, but there are plenty of other times when you might want an external site or some page of your own site to open in a new window. A person is just as likely to be confused by a new window as they are by being taken to another site an having to use their back button. Since web developers have done it both ways with NO consistency, most users expect links to be a crapshoot anyway and if you are like me, you probably open most links by right-clicking and opening in a new tab or window. However, if you just put a little graphic next to your link to indicate that it will open in a new window, then I see little reason for it to be confusing to anyone. I see many people complain that having a target attribute lets sites hijack your browser, but this is utter rubbish. Sites like that generally exploit new windows with javascript, which is what we are all now reduced to doing if we want to comply with standards simply to open a link in a new window. I personally think it was ridiculous to remove the target attribute from XHMTL specs without offering an alternative to using javascript. It’s just another symptom of standards that simply don’t give a crap about the end user or the workflow of the developer. The standards committees never bothered to think about the kinds of things web developers NEED to be able to do, such as having an easy way to lay out a box that can properly grow or shrink to fit its contents, or to automatically scale a box to extend to the bottom or side of the browser window. The lack of a taget attribute is another example. Since I must occasionally open a new window, I have settled on using this javascript to solve my problems. Since the average user I’m concerned would never know how to disable javascript, I don’t see it as much of a problem, other than forcing me to add another kilobyte of javascript to my .js include file. More advanced users, specifically those who surf with javascript disabled are not a concern for me because they generally have an axe to grind over some script that was mean to them and they are used to browsing with limited functionality. They will probably complain no matter how you open a new window, so I ignore them and assume that their natural sense of superiority will get them where they want to be (which is usually some CSS forum where they feign an intereste in helping people just so the can show off their passive-agressive ability to be condescending). I hereby authorize you and everyone else to open a new window whenever you think it makes sense. Use the target attribute and a transitional doctype if you don’t care about strict compliance and use javascript if you do. Ignore the jerks who want you to feel stupid for satisfying your clients and users. They probably don’t have either.

• My blog » Blog Archive » The TARGET attribute in A tags
  September 12th, 2006 at 21:54

  […] al stuff, Web design Robert Nyman gives a good answer on why you should use the How evil is the TARGET attribute in A tags. […]

• My blog » Blog Archive » The TARGET attribute in A tags
  September 12th, 2006 at 21:54

  […] al stuff, Web design Robert Nyman gives a good answer on why you should use the How evil is the TARGET attribute in A tags. […]

• Richard Trigaux
  October 10th, 2006 at 14:32

  Hello all,

  I think there is a serious problem to come for webdesigners if we can no longer manage our windows. It is obvious that any site a bit complex needs several windows to guide the visitor (main nav page, index page, forms, etc) and of several kinds (normal windows, full screen windows with ou without scroll bars)… and it is also evident that only porn sites or crook sites abuse of these very useful features (and the obvious solution is not to go on those sites).

  There was already serious problems with classical solutions such as target and window.open (opening a full screen window, changing from a full screen to a normal window…) but if we let do, we shall soon have only one small window surrounded by numerous menu bars, whatever it contains a little advice, the main content, or a large poetical image which deserves a full screen.

  And nobody to complain!! to post a message to the W3C is a complicated process, and we must pay…

  There is also a hiden lobbying: on every french forum dealing with the full screen problems, we find the same short message telling that full screen is very bad and the guy does ctrl+F4 each times he finds one…

  I think the W3C should rather find solutions to the existing problems (such as normalizing javascript, or defining the window properties in the page itself, not in a link to it) and internet authorities should certify browsers if they are compliant. Not create new problems, not destroy all the existing pages every 10 years… (we already have to update to CSS)

• Likchenpa
  October 11th, 2006 at 10:08

  Thanks to Robert Nyman to keep this page, it is difficult to find places to speak of this issue.

  Two hours to change a page from TABLE and FONT tags to CSS… multiplied by the number of pages on the internet, that makes as much lifetime loss as Hiroshima. And even worse, as the peple killed at Hiroshima at least are no longer unhappy, when rewriting a page to ancient HTML to CSS is rather a tedious task… at the expense of enjoying life, family life and so on. Did they think to this when they decided to suppress these tags?

  OK, HTML needs to evolve, the semantic web is a great thing, but at least, ancient pages should be still declared into their ancient language and still be understood by the browsers, even if we forbid to create new pages with these ancient languages. In place of being threatened to disappear and their authors treated as bad code writers…

  The issue with TARGET and full screen is also a threat to the freedom of expression on the net: We should not present a nice image otherwise than surrounded by menu bars, tool bars and other grey computer gear??? Do they understand that suppressing the full screen is equivalent to CENSORING poetry on the net? The W3C, and Microsoft, and Firefox also, should accept that Internet is not only for computer geeks spending their time to solve useless problems att the expense of real life in the world. It is mainly used to convey ideas and expression. And the vast majority of Internet users look for these ideas, infos and expression, not to find solutions to problems that bad software writers created themselves.

  The problem with full screen started with Firefox. But Internet Explorer and the W3C soon joined to the anti-window censoring. Why do they do this? Who control them? Who do the anti-fullscreen and anti-windows lobbying on every forum, including on this page? That this lobbying presents itself under different names each time strongly suggests that something dishonest is going on.

  I filled a bug to bugzilla-firefox, as F11 no monger works. Still no reply… I tried to reach the bug submission system at microsoft, for the same reason… will you be surprised, there is a bug on their site, and I found myself on a form to create a microsoft passport without even telling me what it is. And on the W3C site, we must pay, and spend hours to find the right place to post a complain (if any such place exists).

  What I say here will probably not be heed by the concerned people, but at least it will be written once in one place on the net: if non-democratic measures destroy our work on our sites, and we can even not complain for this (to obtain more sane measures), this is equivalent to a deliberated attack, and I will use other methods (oh, not violent, not illegal, without noise or scandal, but dishonest people would be well advised to stop fooling about).

• Richard Trigaux
  October 13th, 2006 at 14:08

  Robert, I don’t think that sites “force” users to open in a new window. In a well designed site, the webdesigner tries to guess what is best for the user, eventually guiding him.

  For instance in my site shedrupling.org, I have a main navigation window, where you can go from one page to another without any restriction (all the links are on top of the pages). But I also have forms to post messages to a forum. And all the links to these forms open in a new window, because the user will probably want to compare his writing in the form to my text in the main page. This is impossible to do if there is only one window, we would lose the already filled form. More, I use TARGET=”_blank” to link to these forms, so that if the user starts a new form he does not lose what he was writing in the first form. (Users seldom open many forms, unless they want to test the limits of their system)

  I also have a page with a nice illustration: http://www.shedrupling.org/art/lotr/revelfic.php This illustration is presented at the bottom of the page, in a small format. But there is also a link “see this image in full screen”. Could you imagine the elvish marvel of Valinor surrounded by menu bars? Of course no, from where the full screen. There is even a javascript dialogue box on the full screen page telling how to close it. So I have a very good reason to use full screen, and nobody can seriously pretend that I hijack the user, as some say in every forum. But the real problem with this full screen page is that it uses non-normalized javascript, and it is a developper nightmare (if $browser == “MSIE” do this way, if $browser == “Firefox” do that way, and if $browser=”Opera” I cannot test). All this would rather fit with an image of Barad Dur jail rather than of Valinor, don’t you think so?

  I have another project for this site, having a music background following the user from a page to another. But this needs… a popup window.

  There are certainly real issues about full screen, target and all, but the W3C and browser developpers should rather fix these issues, for instance not letting a site install a software on our computer without us even noticing it!!!! And if users prefer to open all in one window, or into tabs, they should be able to configure their browser that way, knowing that they will lose some basic functions.

• Robert Nyman - author
  October 13th, 2006 at 20:15

  Brett, Richard, Likchenpa,

  Thank you for your comments.

• Rob Cherny
  October 16th, 2006 at 14:37

  I don’t think you should be manually coding in the Target attribute unless it’s under a Transitional Doctype.

  That said, if you’ve scripted it, that’s probably not a bad thing.

• Robert Nyman - author
  October 16th, 2006 at 22:20

  Rob,

  Personally, I’m not a big fan of adding invalid attributes to the DOM, although I guess it is in some sense better than invalid HTML, to begin with. Good article, by the way; thanks for the link.

• Richard Trigaux
  October 17th, 2006 at 8:47

  Putting an invalid “target” attribute into a strict document is not the solution: one day or another, a browser will stop implementing this attribute in this case, and our link will not work as desired. I put my “target” attributes in a transitionnal document; but this is not a solution either, as “transitionnal” means that it is here for only a limited time, so that we take the same risk as with cheating the strict HTML, or worse. Using javascript “window.open”? But javascript is not standardized, and anyway I measured on my site up to 10% people navigating with javascript disabled: a javascript “window.open” link would not work.

  There is no reliable workaround, it is not a coding issue to which there would be a coding solution, we can just do some “transitionnal” hack.

  This problem is really a non-reductible disagreement between the W3C proposal and the interest of web developpers and users.

• Richard Trigaux
  November 5th, 2006 at 11:45

  I would add a thing besides the subject.
  5-7 years ago, it was easy to do a site, it was some tags «HTML» «body» «font» «table», edit WYSIWYG with free Front Page Express and see it exactly the same way with Internet Explorer. Anybody could create a good looking site, even impaired people with low IQ or third world people just knowing to read.

  Today, to do a good page seeable with all the four major browsers (IE, Firefox, Opera, Safari), you need to learn complex CSS, use javascript, and do browser sniffing to adapt your code to the different browsers. This requires PHP and basis of programmation. Clearly only geeks or professionals can do, and common people are excluded of creating their own content on Internet, unless they use poor ready-made templates like on blog sites.

  Browser manufacturers and W3C should seriously consider that browser war, bad browsers (which don’t implement standards properly), improper standards (like dropping “target”) and uselessly complex standards, all these are a real brake for the freedom of expression on the net. Not for THEIR freedom of expression of course, but for the freedom of expression of a vast majority of people in the world.

• Robert Nyman - author
  November 6th, 2006 at 9:48

  Richard,

  I would say that the WYSIWYG tools wasn’t any solution back then nor is it now. It worked in Internet Explorer, but in no other web browser.

  For me, working as a web professional, browser sniffing doesn’t need to be done for PHP and the likes. The only sniffing necessary is done, through conditional comments in the HTML code, to serve IE and its insufficient CSS support (and yes, that goes for IE 7 as well).

• Richard Trigaux
  November 7th, 2006 at 10:56

  A long time ago, Front Page Express was THE only editor, Internet explorer was THE browser, and «HTML»«body»«table»«font» was THE correct way to code a page. Of course this changed with the appearance of Netscape, but in the begining it was rather a political step against the monopoly of Microsoft, rather than improving the standards. Improving the standards came later with the CSS and the like.

  An example of CSS difficulty which can be solved only with browser sniffing:
  A transparent clickable zone in front of an image (a common and perfectly legitimate method).
  With IE you need the style:
  background-color: gray ;filter: alpha(opacity=0);
  With Firefox you need:
  (nothing)
  With Opera you need:
  background-color: gray;opacity: 0;
  With Safari you need:
  (not tested, I don’t have a Mac)

  If you know which of these CSS is the correct recommended method for doing this, please tell me, I will change all my PHP browser sniffing routines to switches, and place the standard method as the default: case. The browser which never appears in any switch is the winner. (Useless to say IIE6 has little chances to win).

  Another example: try to center vertically a text in a block.

  Another example: try to share a block in two columns of equal width.

  Another example: try to hide a text (anti-spoiling) with an opaque div which becomes transparent when you hover the mouse on it.

  What I think is that CSS is a great thing, yeah, but I already have done only three pages, and I already stumbled on more that three unworkable issues like these. Not to speak of the topic of this thread, suppressing the «target» attribute, because, they say, some simplified browsers don’t support multiple windows (Yeah, if bykes carry only one passenger, so cars must too carry only one). Or the other “very good reason”: beginners don’t understand the behaviour of multiple windows (This is as if we simplified orthography, because beginners can read only simple words).

  What I think is that they should allow most people continue working in the ancient way («HTML»«body»«table»«font») which is easy to use and far enough in many cases (The pages I translated in CSS don’t appear better than in former HTML, except for % screen size adaptation). And, for CSS, it is OK, but they should put people able of normal common sense to work on it, to implement the obvious solutions to the problems I quote above (and many others, if I extrapolate).

  You know, if there are common and legitimate thing we can no longer do with a new standard, it is simply that this new standard contains mistakes. This is something human, something which happens, there is no shame to do mistakes, it is not an heresy to show mistakes, and the obvious and only solution to this is to correct the mistakes, not to invent who knows what ad-hoc theory as that it would be bad to do the things we can no longer do because of those mistakes.

  Thank you again for maintaining this page. I am seriously considering creating another one myself on this topic, because I am really fed up to spend days to work issues which needed only an attribute in ancient HTML.

• Robert Nyman - author
  November 7th, 2006 at 11:28

  Richard,

  I have been developing web pages since 1998 and FrontPage has never been the editor for me (except for the obvious validation round). I have always used HomeSite to have clean code that I can control myself.

  Opacity is beyond what most people want to do with CSS, in my opinion, but just to answer your question. With opacity it is the same case as with most other things: there’s a standard way and a Microsoft way. You use opacity for any web browser but IE, and for IE you need to use their filters.

  Vertically aligning text is about having a block element within a block element, alternatively using the display: table-cell CSS property (again, not supported in IE).

  And so on…

  There are ways to achieve many things in CSS, and the advantages vs. table-based layouts are many. Less downloading time, less and more manageable code, better performance since the CSS is cached, separation of content and presentation, being able to instead have semantic HTML for search engine and accessibility reasons and so on.

• Richard Trigaux
  November 7th, 2006 at 16:46

  Yes, I understand that professionals never used FrontPage, for obvious reasons. But millions of people did, as casual web designers. Anybody who wants to create a site to express an opinion or present something, will do it once, and thus will not buy professional tools or learn complex things, and will not bother about having the best code.

  About my example on opacity, I am not seeking to use opacity, but to create a transparent clickable zone. You get the difference? Opacity is only the mean. You could call it hshdjkdkfkf as well. Alas this mean is different for all those three browsers, not just with IE. All those tricks are well known by a professional like you, but they are a real problem for anybody who just wants to create a site once. In this way this complexity is hampering the freedom of expression of all those people, the vast majority of sites.

  And I don’t oppose CSS, I agree with all your arguments, I just regret it contains so much avoidable tricks and traps.

  Thank you for your tips, I shall try them. And if I can vertical align my text with a given browser and not with another, so bad for the later. At a pinch, if there is a function which completely don’t work, I will place a message suggesting to use another browser. I already did this with IE, untill I found a workaround. But they will probably get another punishment of this kind, as they suppressed the full screen, completely messing a hundred of my pages of art work on “the marvelous world of the Eolis”. Firefox could be the next on the list, if they continue to reduce access to the the full screen mode.

• Richard Trigaux
  November 8th, 2006 at 10:17

  Excuse me to post again without waiting for a reply, but I think the problem in this domain, as in many other domains, is that everybody grasps at his opinion, seeing only the advantages of the system he supports, and getting blind to all the defects and inconveniences of this system. This is hust polemics, rethoric, not a fair exchange or discution. (Please don’t take this as personnal!!)

  It is however well known, in this 21th century, that we progress only when we eliminate our defects. Thi is true for great moral concerns, but also in down to earth issues like computer science. But this requires the will and ability to face our mistakes, and the humility and courage (yes it is the ultimate courage) to see our mistakes and correct them.

  In the beginning I was a strong supporter of free softs, for political/philosophical reasons even far before computer reasons. But my experience with this turned to the nightmare… I would sincerely regret if the only result of the whole linux/firefox experience would be to push ahead Microsoft in the way of improving its products (a thing it could easily do, with ten of thousands of developpers, if one day some rational person takes the commands).

  Same for Firefox: I posted two bugs in bugzilla, on the full screen problem (a painful issue for me and for all artists). The first time, I was abruptly rebuffed, the second time just ignored… this is very far of what is called “a friendly community of developpers”…

  Same with CSS. The CSS spec is not a divine commandment, which would forbid us to do certain things (such as using multiple windows with the «target» attribute, or other ununderstandable taboos of this kind). The CSS spec is a human building, with human authors and maintainers, which would easily be bettered with some simple fixes. The problem is that passing a message to the authors of the spec seems as difficult as speaking to the author of the ten commandments 3000 years ago on the Sinaï mountain…

• Robert Nyman - author
  November 8th, 2006 at 10:28

  Richard,

  …passing a message to the authors of the spec seems as difficult as speaking to the author of the ten commandments 3000 years ago on the Sinaï mountain…

  Ha ha!
  Maybe…

• Richard Trigaux
  November 8th, 2006 at 23:17

  Robert,

  happy you did not take it as personnal.

  But I hope concerned people will move…

• Richard Trigaux
  November 17th, 2006 at 12:18

  Me again, hahahaha…

  This page http://www.shedrupling.org/art/lotr/revelfic2.php
  features a nice illustration (in the bottom) with a link “click to see in full screen”.

  When I designed this page in 2004, it was enough to use a javascript link onclick window open, some more lines of javascript to adjust the image size to the screen, and waow the magical paradise of Valinor popped up in all the screen making forget it was just a computer screen. (to close, just click on the image)

  It was THE standard way of coding, it worked with IE, and with Firefox as well. But Firefox made the full screen more difficult… and recently IE frankly suppressed it!

  So that, today, I had to redesign this page, to cope with all the quirks an tricks of this full screen mode, according to various browsers and users who disable the javascript, placing warnings and all to guide the user… that makes 380 lines of code, 9 PHP functions, a state machine to manage all…

  I though the case of Opera would be the simplest, but they have a useless “fit to width” option which… unfits my screen adaptation, so that I have to warn the user so that he may disable this…

  Is all this mess really a progress?? Is really Internet better because of so many useless hassle? If we keep with a Tolkien comparizon, I shall call it the crooked way toward Valinor…

• Richard Trigaux
  November 18th, 2006 at 9:02

  Please corrrect the URL above: http://www.shedrupling.org/art/lotr/revelfic.php
  (revelfic2 was a draft)

• Olaf ‘Rhialto’ Seibert
  December 19th, 2006 at 15:07

  It seems that all the problems with the target attribute are actually only with target=”_blank”. It is, IMHO, stupid to throw away the whole attribute just because of that one (potential mis)use. A perfectly good use is with frames, where the links in one frame (the menu frame) load pages into the other. It is very unlucky that a setup like that would need javascript, since I have always maintained that a properly designed site should be accessible without javascript. After all, javascript can be misused a lot more than the target attribute…

• Podophile » Blog Archive » Podophile 2.0
  January 8th, 2007 at 10:29

  […] as of today, full Podophile feeds for all. target=”_blank”. I stumbled across […]

• Ally’s Blog » Opening New Windows!
  January 9th, 2007 at 15:48

  […] aScript open browser window pool. Now before anyone shouts at me, or calls me evil for using the target attribute, you do have admit its pract […]

• Richard Trigaux
  January 29th, 2007 at 11:43

  Hmmmm…. Why the target “_blank” alone would be a problem? It is very useful into a link page, to send the user toward the various sites without losing the link page, or to send the user toward an accessory page without losing the main. It is very frustrating when we browse a link page and we lose the main page. So when I design a link page I do what the user needs. Personally I often need “_blank”, but never had the occasion to use the three others.

  I am afraid that many “reforms” of the Internet don’t arise from a real knowledge of user needs and page display needs, but, for whatever reason, of a very restricted view of only a special case.

  Yes some attributes like “_blank” or opening POP up or full screen can be misused. But we can misuse cars too, to run into somebody and attempt to kill him, and even with a simple table knife. Must cars or knives be forbidden for this reason? Wake up, the world is much larger than any of our personal scopes…

• Duane Alan Hahn
  February 8th, 2007 at 18:24

  You may have heard that if you have good content, people will come back no matter what. That’s only true if they remember the name of your web site. You could have the best content in the world, but if someone surfs in from a search engine, loves your web site, then leaves a few minutes later by following an external link, they will probably lose track of your site unless you open the external link in a new window. Haven’t you ever become slightly angry because you didn’t get a chance to bookmark a cool site that you stumbled upon? That has happened to me many times and I’m sure it has happened to other people too. I used to hate offsite links that opened in a new window, but now I appreciate them. The new window allows me to explore freely without fear of losing the original web site.

  Sometimes you don’t want to use the back button if you fill out any kind of form at another web site, so the original site may be lost although you really wanted to go back there. It’s much easier to simply close a window so you can get back to the original site. So people who complain that opening a new window “breaks the back button” of the browser need to understand that many times, the back button becomes useless anyway.

• lillbra » Blog Archive » Target-attributet och öppna länkar i nytt fönster
  March 8th, 2007 at 8:16

  […] an fÃ¥r dÃ¥ ett valideringsfel i sin kod. Robert Nyman tar upp detta alternativ i artikeln […]

• Igor Levicki
  July 15th, 2007 at 6:56

  Killing target attribute was the most stupid idea and I am glad that modularization brought it back.

  You need new window for:

  - Flash site (back button doesn’t work anyway)
  - Media players (they crash and burn and you lose back button functionality again)
  - PDF documents (they have their own back button)
  - Showing large images (you can continue reading while they load, especially on slower connections or if you are downloading other things in the background)
  - Forums (managing attachments for the posts for example)

  There are many other circumstances when you might need a new window, one of them being on the site where you get “warning: page has expired” when you click on the back button (reason: security of transaction), and you can’t go back to the site you were before and thus you lose the link and have to retrace your steps to get there which is sometimes impossible (for example because of updated Google pagerank in the meantime).

  Given all this, removing target was a bad idea. Allowing it through the module is a step forward after taking two steps back. Integrating it into XHTML 2.0 would be a much better thing to do.

• Igor Levicki
  July 15th, 2007 at 7:01

  Sorry for the second post, but I forgot this:

  - You need new window for sites where you need to make it clear that you are not responsible for the content which opens in a new window.
  - New window is preferred for offsite links.

  I also forgot to mention that javascript hack doesn’t work with sites that check referrer.

• Jane Carter
  August 10th, 2007 at 22:43

  What would be *really* useful would be an attribute “open in new tab”. You are correct that one of the problems with the target=”_blank” attribute is that most people nowerdays used browsers which support tabs.

  Or how about a JavaScript which produces a little POP-up menu offering users the choice of opening the page in a new window or in a new tab?

• Richard Trigaux
  August 22nd, 2007 at 21:30

  yes, opening in a new tab. But it is t up to the user if he wants to open new pages in a tab or in another window. There are arguments in both way, especially that if we use windows we have the tabs in the system tray. So the attribute “_blank” is enough for this.

  The problem come when the site needs a special window, full screen, or “half” full screen (no menus, but still the cross and the system tray) or small POP-up windows