The target attribute and opening new windows

The target attribute is not allowed in strict doctypes, and since you should always use a strict doctype, the target attribute is invalid. Period. Unless you use frames, which you should not.

Opening new windows is a nuisance and should be avoided. There are very few cases where a new window is acceptable. If I was forced to open a new window I would definitely use unobtrusive JavaScript instead of invalidating the markup by inserting a target attribute.

My reasoning is that validation is a very useful tool. By deliberately inserting erroneous markup you make that tool harder to use and thus less valuable. Harder to use? Yes, because each time you validate a document you will get validation errors that you need to filter out before you can tell if there are any other, “real” errors.

Most important though: If you, for whatever reason, decide to open a link in a new window, make your users aware of it and if possible give them a choice.

Comments

I totally agree. PDF, or any other file type for that matter, is no justification for target=”_blank”. If you are linking to a PDF document, it should be clearly indicated anyway. Probably the best site at clearly denoting various link types (zip, etc) is Particletree. This gives the user fair warning that it’s not an HTML page, and allows them to right-click + download, or proceed normally. Ultimately, as you said, it should be up to the user.

Most important though: If you, for whatever reason, decide to open a link in a new window, make your users aware of it and if possible give them a choice.

Good point. And because there are “real users” who want links opened in a new window, I made my thoughts about that topic a few weeks ago, to discuss the use of the target-attribute. Unfortunately only in german: is it realy disused?

The following discussion shows, that even when users want links to open in a new window, the “standardistas” among us are fiftyfifty and suggest different fixes to this issue…

PDF’s and the like should open in a new window. Two reasons: 1) most people click on the PDF then close that window, thus losing the site they were just in. 2) opening items in a new window seems like an easy task but I imagine most general users (like your mom) just really don’t know how.

It’s weird… I agree entire with your conclusion but not with any of the reasoning except the one that’s important: give users a choice (viz. “always open external links in new windows?”)

At the risk of derailing the conversation, I will say this:

There is no reason to use a Strict doctype that will result in any financial or otherwise material benefit. Most people who do so do so just to say they did so.

If you agree with #1 (which you definitely don’t :) ), then the validation thing doesn’t come into play… BUT, onto validation:

I agree that validation is a useful tool, but are you really making it any less useful by having a few “target” attributes in there? I know it’s nice to see the little congratulatory message in the validator saying you’re valid, but having to scroll past a few target attributes really isn’t that bad at all. If you want to talk about bad, let’s talk about what ampersands do to the readability of the validator! If your ad tracking code and your other parameterized URLs don’t have their amps encoded, then you’re all of a sudden having to wade through several hundred “errors”. If you ask me, this is a problem with the validator as much as it is a problem with people’s code. The validator should be a lot more helpful with this sorts of things: period. Instead, because of the “all or nothing” mentality, there is no way to tell the validator “ok, ok, I know I have this ampersand problem… please ignore it and just help me fix my other stuff”. When need a more humane validator if we’re going to get more humans to care about validation.

The basis of these conversations are usually that the user should be the one to make the decision about whether a link opens a new window or not. The problem I have with this is that it assumes that all users know how to open a link in a new window and therefore are able to make the decision themselves. Many newbie type users do not know how to do that. So they don’t have a choice, they have to use the website as it was designed, by you. In some cases (such as the aforementioned PDF issue) maybe it would be better for them to have the link open in a new window.

You can argue forever about whether the target attirbute should be allowed in strict or not, but what it comes down, IMO, to is whether it improves the user experience or not. Of course, there are many factors that contribute to that decision and it would have to be made on a case-by-case basis.

Personally, I don’t think that the occasional target= attribute is anything to worry too much. There are many more important problems for a web designer to spend his/her time on. I’m all for standards, but if a few target= attributes make my code invalid then I’m really not that bothered by it. (see Mike D’s third point, above)

Most important though: If you, for whatever reason, decide to open a link in a new window, make your users aware of it and if possible give them a choice.

I am completely agree on this point. Actually, the target=”_blank” if one of the few things I hate browsing in the Net. Another useful article on this topic - by the way, thus you can let the visitors decide, where the links should be opened.

If you want to use target, then just use a different doctype that allows it or add it yourself into your own custom doctype. Mike, I understand you have this thing with validation - and that’s cool. I say, just lower your strictness, it really is no big deal. Follow the rules you lay down and all is well.

Re: Usability of a new window, well, that’s another topic. But I like the idea of choice, I think people can dig that.

The reason why it was taken out was because it’s an unexpected behavior, and thus creates a bad user experience. The best valid way around it, if you have to have it, is to use rel=”external” and JavaScript to open links with that attribute in a new window.

Dustin: Yeah, custom doctypes are fine. I don’t mind them. But, meh, you can make a custom doctype which lets you write gobledeguk as well. Doesn’t really buy you anything in the real world. I am not really anti-validation at all… I just don’t view it as a binary thing (even though it technically is). All I’m concerned about are two things: 1) How good is the user experience, and 2) how efficient is the code.

Jonathan: PDF files and the like could open in a new window, if you warn the user and give them an option not to. I hate getting an empty, orphaned window after clicking a link that

doesn’t tell me it leads to a PDF file

assumes that my system is configured to display PDF files in a browser window (it isn’t)

assumes that I want to read the PDF file in a new browser window

As long as the site author is kind enough to inform me that the link will load a PDF file and open a new window, I can choose to save it to disk instead of becoming annoyed.

Mike D.: Heheh, yup, I like my markup strict. And I don’t just to say I do so ;-).

I get your point about validation, but I really do feel that once you start accepting certain errors that may not be critical, validation as a quality assurance tool becomes much less useful. You’ll end up having a checklist of your own. “Ok, let’s see, we allow target attributes, unencoded ampersands, input type=”search” and…”. Sure, you can handle it up to a point, but then what? And where do you stop?

If you feel you have to use the target attribute, use a transitional doctype.

I agree though that unencoded ampersands in external code may need to be accepted, and being able to configure the validator to ignore those errors would make validating the rest easier.

Megan: In some cases, maybe it would be better for some people to have a new window open. If they use a windowed environment. If they are capable of understanding that a new window has opened. If they understand why the back button suddenly does not work.

Again, always inform the user before opening a new window. My guess is that there are extremely few people who would be annoyed by knowing what will happen when they click a link. :-)

As for how to inform the user, a title attribute on the link is not good enough. It needs to be more obvious than that.

@Jonathan Snook:
There acctually has been studies of how people react to new windows by our favourite Jacob Nielsen. Say what you want about that guy but he does add something useful to the mix: real usability studies.

The “ctrl + click” combination remains the best way, but for those that don’t know it and use “right click + uhm, where is that option…furl this page no…colorzilla no… ah ok. + open new tab”, the absence of a target is not a good support to a rage-less navigation.

…if you like your markup strict, then why would you use an unobtrusive javascript to insert your target attribute? Why does having it inserted by the DOM make it any more okay to use invalid markup?

You’re not the first one to suggest this by any means, but I’ve never been able to figure it out. What you are effectivley saying is, “it’s okay to use invalid markup, just be sure to tuck it away in javascript so the validator won’t see it when someone validates your page.”

Personally, I’m with Mike D. on all this. I’m not a big fan of opening new windows, myself, but if you want to use it then use it. It’s pratical and effective, which beats “valid at all costs” anyday.

I recently posted an article on this very topic. Unfortunately, most of the people who visit the page find it through search engines, so I’m assuming they are looking for the technique rather than the argument against it. I know of several “standards” advocates who serve strict document types and hide the fact they’re using target attributes with JavaScript.

I personally despise the practice, and even managed to get the Newsvine team to stop doing it on their links to external articles.

Personally, and perhaps this is just my own preference, but I think of viewing a site as it’s own browsing experience, and if a link goes to another domain, it should create it’s own contained experience.

I think choice is good, but personally, I think external links should create a new window.

Silly that this conversation comes up at least once a year. I don’t think any of us can really declare what is more useful. Some like popups, some don’t. The idea of choice IMO is really the best solution.

If you’re going to open up a new window, then just tell the user (this link will launch open a new window).

Letting the user choose is one thing… assuming they actually know they have a choice is another.

Anecdotally, there are plenty of people who barely know how to click a link - much less use relatively advanced window control eg. choosing between the current window, a new window, a new tab or a new background tab - suddenly they have four options.

Basically, I’ve found the average user has a disappointingly low level of knowledge about their browsing software. I had always assumed that people would pick up something over time, but it seems not!

So, I am comfortable with the idea of second-guessing a few things. External links? Either set them all to open in a new window or give the users a page-based choice - eg. a checkbox to “open all links in new windows”. PDFs? New window, with a silent curse at Microsoft for opening non-web documents inside their web browser.

I think the basis behind unobtrusive JavaScript is not hiding from Validation.

It is simply if you use unobtrusive JS to open a new window and JS is not supported or turned off, the link opens in the same window. Other JS ways would try to open a new window when JS is not there and the info would not be accessible.

Keep in mind:

a) You are in end effect forcing something on me.

b) Not all user agents support JavaScript, common opinion is 10% have JS turned off, but you have the possibility that 100% of users CAN turn it off. Much of Europe uses Cell Phones to surf, PDAs and now game consoles and portable game players can surf as well. Browsers are not the inly user agent available and not all user agents support JS.

Let’s hope that the Jacob Nielsen study (comment #15) puts the PDF opening in new windows issue to bed when it comes to designing sites that ‘cater to the masses’.

My own usability testing has confirmed that regular web users (not web designers or developers) far more often than not will close down the browser window in order to close the PDF.

There’s really no point in adding an icon to indicate that the link opens in a new window as regular users won’t know what it means and will ignore it. Nor do they know how to right+click on a link to get more options.

My recommendation: label the document as a PDF, indicate the file size and use target=”_blank” or rel=”external” and call it good.

One method I once used in a small project was adding (with unobtrusive javascript) an extra link enclosed in brackets behind a link with rel=”external” which reads “(new window)”. I put it in a smaller fontsize and different font-face to minimize interference with reading the text. It worked well but still several inexperienced users were confused as to which link to click to actually open the link.

I thought about adding a javascript alert when a user clicks a link for the first time (remember with a cookie) explaining the difference between the normal link and the one enclosed in brackets.

There’s really no point in adding an icon to indicate that the link opens in a new window as regular users won’t know what it means and will ignore it.

Indicating that a link opens in a new window should be done with text, not an icon. How can clearly stating in the link that it will open in a new window be a problem? Novice users will realise what is going to happen and power users can choose to save the file to disk instead.

During usability tests that I have conducted, the concept of opening new windows for certain actions came up.

The basic findings were that users who understood window/tab management were annoyed when new windows opened because they preferred to make that choice themselves. The users who didn’t really have a handle on window management got confused because their back button no longer seemed to work (this was particularly true of IE/Win users running their browser maximised).

It’s the former point that annoys me. As a user I can’t stop new windows/tabs being opened when a target attribute is applied to the link - so the choice is taken away from me. But I wouldn’t want to unilaterally configure my browser to make all links open in the same window, because there are still some instances when a new window is desirable - although the only ones I can think of immediately would be popup windows for logins or contextual help.

Let me start with saying that I naturally agree that the user should be informed if a link opens a new window, it shouldn’t just happen.

If you feel you have to use the target attribute, use a transitional doctype.

An important point is missed when suggesting a less strict doctype and using the target attribute: rendering modes. For most consistent rendering while also being pressured to implement best practices, one wants to go with a strict, full standards mode.

A transitional doctype can only give you the almost standards mode in a web browser, something that definitely isn’t desired.

Richard: Yes, login windows and contextual help are about the only exceptions I can think of as well.

Robert: Thanks for pointing that out. I didn’t want to bring it into this discussion, but maybe I should have ;-). Yet another argument for using unobtrusive JavaScript instead of the target attribute.

I developed a Flash-based audio player for a couple of musician clients that opens in a small pop-up. This was the only way to allow people to continue listening to songs while browsing the rest of the site, or even browse away from the site. The other alternative was frames (which I originally did employ for this reason).

I decided that this (a pop-up) was the best possible compromise to all the needs and requirements in play at the time.

The target attribute is not allowed in strict doctypes, and since you should always use a strict doctype, the target attribute is invalid. Period.

Bullshit.
(Edit out if you like, but that’s exactly what this is.)

Target is invalid in the strict doctype. It is absolutely valid in several other cases. Whether you think transitional doctypes are wrong is another matter, and ultimately not the issue, and whether your belief is correct is debatable. What’s important is validating to the doctype being used; you don’t get a vote as to what that is.

Don’t mash your opinion in with the facts and just hope that people coming here to learn(and you know they are; take some responsibility) will immediately separate them. Not seeing the (already-discussed) irony in suggesting the addition of targets via Javascript only serves as example of the tunnel vision that tends to lie behind pronouncements like this.

Su: You’re absolutely correct that the target attribute is allowed in transitional doctypes. Did I say otherwise? No. I am confident that the people reading this are capable of realising that.

Yes, it is my personal opinion that you should always strive to use a strict doctype, but the fact is that transitional doctypes are meant for a transition from tag-soup to modern markup. From W3C’s HTML 4 Transitional Document Type Definition:

This is the HTML 4.01 Transitional DTD, which includes presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

I am in no way suggesting the addition of target attributes via JavaScript. I don’t know where you or anyone else got that idea from.

I completely agree with Mike D. and Megan. We have to get this idea out of our heads that validation is a goal, it isn’t.

Validation is nothing more than a tool. And the only people who give a hoot about validation are the types of people who read these types of threads on these types of blogs, and that’s all.

I’ve seen no compelling reason to use a strict doctype other than to say “I use a strict doctype.”

In the vein of what Megan said, there are still highly valid reasons to use a pop up window, where target it is fully reasonable to use target.

I’m all for standards, validation, unobtrusive javascript - it’s all great. What I’m not for is going overboard with these concepts. And we can have the same conversation about innerHTML if you’d like :)

Do what is best for your user in context. If that means having a few targets, so be it.

Tom: Of course validators are just tools, and each of us may decide how blunt we wanna make them. Personally, I prefer to keep them pretty sharp - and choose an option (DTD) that suit the task.

Making ‘almost standard mode’ and ‘standard mode’ render the same, is usually not a problem that can’t be solved in CSS. I tend to code for ‘Strict’, and change the Doctype to ‘Transitional’ if I want to include some ‘non-Strict’ elements or attributes.

I can see ‘opening of new windows’ as an acceptable solution in a few scenarios. I’ll have a hard time coming up with a scenario where ‘opening of new windows’ is a good solution though.

As a user I catch all kind of ‘new windows’ and make them open in the same window/tab - or not at all. The result depends on how well thought-out the ‘targeting solution’ is on any particular site.
This is just to say that it is hard to know what is best for a user.

As a Firefox user who is quite used to tabbed browsing, I too found links popping up in new windows annoying. If I want a new tab, I middle click. If I want it open in the same page, I single click. So I didn’t add any target links in the simple blog I was running, feeling that the choice should be left up to the user.

Later, I was talking to a friend online and he mentioned that he found the site navigation less confusing when I used Blogger.
I do use Blogger, I stated.
Oh, now I’m on a Flickr page.

By not opening a new site in a new window, he had become confused, thinking he was still viewing the same site. So I went back and changed all external links to target=”_blank”, figuring that my initial design choice was only appreciated by power users. Users who can quickly adjust to something different. Reading this article, I may have to look into that again.

Then again, it’s a simple blog meant for friends and family. It may not be worth the effort to help the percentile of users that would have an appreciation for another technique.

Down with target, let the people decide. There are too many different habits to justify using one method (target or JS) to open new windows, without making it clear and optional.

Because people have been trained to live with badly designed websites doesn’t mean you should repeat the same mistakes.

New users will progressively learn how to use tabbed browsers (IE7 anyone?) and those who can’t learn anymore can’t be the reason to hinder everybody else’s experience.

As for validation, there’s a similarity here. Developpers who learn to write HTML (and CSS and JavaScript) with standards in mind, and using the validator at every stage of the development, will find it extremely easy to have 100% valid strict documents. Because there is nothing you can do with invalid code that you can’t do with valid code. Therefore there is actually no use for invalid code and not the other way around.

I have to say that my main problem with the javascript is that often people use codes which prevent me opening a link in a new window, as instead i get something like javascript:popImage(‘../screen1.jpg’,”) which is really irrataing.
I usually don’t open in new links apart from on my link page where they all do as most sites do that so I don’t feel it’s a problem from a usablity perspective. The links pages are all transitional to help with validation.
As for PDF files I don’t like them ever so I’m not that bothered although with IE people are quite likely to close the window I imagine.

Yes, but why should one always use a strict doctype? I have yet to see an argument for this that actually makes sense. By which I mean the “always” part. Oh, they’re all logical enough, but they consistently fail to lead up to an absolute rule that Strict Must Be Used.

All seem predicated on the belief that strict is better, which is more than a bit disingenuous. The simple reality is that it’s nothing more than “other.” While the two doctypes may be very closely related, they are not comparable. A transitional document is operating under a different set of rules; only slightly, but still: different. And as long as they are adhered to, there is absolutely nothing wrong with it.

I’m surprised to see that there is such a debate over this issue. Clearly HTML is a markup language, and clearly the target attribute is a UI-specific attribute. In a non-windowed environment, target makes no since. It never should have been a part of the HTML spec, and it’s a shame that so many people are bent on telling their visitors how their browser should work.

The main advantage to using a strict doctype is that it does a better job of encouraging/enforcing the separation of content from presentation, since it allows very little presentational markup.

Thank you, Roger - this is the exact statement I was thinking almost the entire way down the comments.

In the same way that Ruby on Rails separates an application into the Model-View-Controller concept, entire websites could be divided into a content structure/presentation/make stuff happen concept in the forms of HTML/CSS/Javascript. target=”_blank” will remain deprecated in the Strict doctype for this reason.

I agree that people should be given an option on whether or not to open a new window, but I also think that web designers should not shy away from having new windows open with JavaScript upon following links if it works for their users. I have always found it to be a major pain to be required to use the back button in my browser because the website I was just visiting forced me out of that website’s navigation structure. On a slow computer or internet connection, it’s always easier to close a window than hit the back button.

Tabbed browsers aehv made life easier with this - on the Mac for example I just control-click the link these days if I dont want to move from the page I’m on so there’s little justification for it now really.

Right, documents should validate, and strict should be preferred. But it’s a common misconception that the dreaded target attribute is deprecated or something. target is still included in XHTML, but it’s simply not in the basic set. That’s why XHTML is extensible, module based. Simply use XHTML and bring in the target module. That’s all. You have validating, strict XHTML (even XHTML 1.1) plus target, and the W3C approves it. Not evil at all. At least I think it’s much more elegant than any crude JavaScript hacks.

Okay, web accessibility guidelines say that websites should validate against public DTDs. But though one could argue this is “my own” DTD, it’s still public, and it uses nothing but original W3C DTD modules, so I suppose it’s okay and the way the W3C meant eXtensible HTML to be. Still it’s rarely observed in it’s natural habitat.

Anyway, I hate popups, but I think new windows (or tabs) are okay as long as the user has been warned. Discussions about the German implementation of the WAI guidelines agree that it’s enough warning if you use the title attribute with something like “external link opens in new window.”

About PDFs: Don’t open them in the browser, please open them in the PDF reader. That’s one line of code you add to your Apache’s .htaccess or httpd.conf, and it works like a charm.

“but I really do feel that once you start accepting certain errors that may not be critical, validation as a quality assurance tool becomes much less useful.”

Thing is, these are called errors because someone who doesn’t like the attribute says it’s an error.

I know many users that dislike having a link take over the page they found it on. They get frustrated because they’ve lost there place, oops closed the window and didn’t have the page bookmarked, got sent a link in a chat or something…

Personally I have _blank’s on my index page that opens new windows to display designs. I even asked a majority of my clients if the new windows bothered them and they ALL said they would rather have it open a new window than hijack the main page.

They can simply close the “preview” window when finished then tada.. looky there, the index is still there waiting for them to open another design window.

And the JavaScript thing would be fine but again, I go back to my clients. I once used a pop-up for a contact form and got complaints from the client that wanted to know why I was using “malicious” scripts on his web site.

Needless to say I had to giggle, but he went on to tell me that a “tech” told him to disable “java” because it was used by hackers to take control of computers.

So then there I was trying to explain to him that the tech either didn’t know what he was talking about or he misunderstood what the tech was telling him. Either way I’d rather not have to worry about such goofiness. :P

Besides all that you shouldn’t “have” to design a layout so that some little pop-up icons will somehow look nice.

Finally someone mentioned the problem with Javascript… The user can disable it, or even worse the plethora of “Internet Tools” (popup blockers, spam protectors, add-on tool bars) that all want to control your browser use. Especially what they consider to be “malicious” Javascript code.

On another note, the PDF issue of opening in the reader doesn’t necessarily apply when you have dozens of users uploading content (quite often PDFs) and they are not technically proficient enough to follow directions (or not inclined to follow directions) for making the document open in the reader.

I don’t see a big issue with the target=_blank as long as the user is informed of what’s happening, it’s not overused, and you are consistent in your application of what opens in the current window and what doesn’t.

By the way, a “standard” that I see developing is the use of the little icon of a box with an arrow pointing out of it (Wikipedia and CNN). It’s unobtrusive and let’s the user know they are either going off the site or opening a new window.

It’s nice to live in the Gilded Castle of Standards, but I need the website to work for any user, not just the ones who haven’t disabled Javascript or are using a standards compliant browser.

It’s nice to live in the Gilded Castle of Standards, but I need the website to work for any user, not just the ones who haven’t disabled Javascript or are using a standards compliant browser.

How does this not work if JavaScript is disabled? How does this not work in a standards-deficient browser (IE)? The only “problem” is that the designer cannot force their will of opening new windows on a whim to “keep visitors on their site” upon users. If anything, people with JavaScript disabled or ancient browsers will be rewarded.

We have some external links on our site which are presently target=”blank”. We would very much like to change this so that the new pages open in a much smaller browser window, so that our users don’t lose touch with our site when the window opens. Could you suggest a JavaScript which would do this, but which would default to target=”blank” or the equiv. for those users who have JavaScript disabled? It is important that these links are visible for everyone. Thanks for your help, Jane.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.