SimpleQuiz › Part XVI: Launching Windows

This question comes in from Keith Robinson — and it’s a good one. Recently, Keith had been working on a project using the XHTML 1.0 Strict doctype — but ran into a dilemma when he needed to launch certain links into a new window.

No worries, the target attribute is all we’ll need here:

<a href="somewhere.html" target="_blank">link</a>

But sadly, the target is deprecated and unallowed in XHTML 1.0 Strict (probably lumped in with the demise of frames). So we have a few options. We could stick with Strict and use any number of JavaScript methods to pop the new window. Or we could be rebels and use the target attribute, ignoring validation errors. Or lastly, we could switch to the XHTML 1.0 Transitional doctype and use target, staying completely valid.

Q: When using the XHTML 1.0 Strict doctype, how would you launch windows in a new window?

  1. Strict doctype + JavaScript pop-up solution
  2. Strict doctype + target="new" + Ignore validation error
  3. Switch to XHTML 1.0 Transitional doctype + target="new"


  1. BacMan says:

    I use method A. This is the JavaScript function I use, which I found on the Web some time ago. I don’t like B. C is a possibility.

    function externalLinks() {
      if (!document.getElementsByTagName) return;
      var anchors = document.getElementsByTagName("a");
      for (var i=0; i<anchors.length; i++) {
        var anchor = anchors[i];
        if (anchor.getAttribute("href") &&
          anchor.getAttribute("rel") == "external")
 = "_blank";
    window.onload = externalLinks;

  2. jason says:

    Choice “D”. Keep the doctype and use:
    <a href="somewhere.html#id">link</a>
    The user goes to a new page where #id is the div,list,etc. of the links.
    Provide a return link back using simliar #id’ing. No pop up needed.

  3. #lama says:

    Definitely A, but just for few links.

  4. Adam says:

    I would have to go with C here – switching to Transitional doesn’t affect anything significantly as far as style or structure goes and you don’t have to exclude those infamous users, whoever they may be, who browse w/ Javascript off (even if they can still follow the link, it won’t open in new browser window like the designer intended).
    So, C.

  5. rADo says:

    Definitely C. Opening windows in a new window is a bad habit, but… XHTML 1.0 TRANS is a perfectly valid W3C norm. Going with XHTML 1.0 STRICT, just for “STRICT” sounding good, is, ehm, stupid. That is validity for sake of your own ego only ;)

  6. Tate says:

    I’d have to agree with Adam, however, if a strict doctype would be absolutely necessary, I would give up on new windows entirely. C

  7. quis says:

    Youngpup’s solution is by far and away the best I have seen for this. It works for users without JavaScript, it validates and you can still “open in new window/tab” and “bookmark link” should you so desire.
    So A basically.

  8. MoeGreene says:

    How about this?
    <script type=”text/javascript”>
    function xl(url)
    return false;
    <a href=”” onclick=”return xl(this.href);”>foo</a>

  9. Keith H. says:

    Ian covered this a while back in his article , Standards-Compliant New Windows. In it Gez Lemon basically explains that XHTML is modular. The target tag, though depricated, is a valid module in XHTML. His solution is to create your own DTD and include the target module. Then you can use the target tag in XHTML 1.0 Strict and still validate.

  10. Jeremy Flint says:

    I like the Youngpup solution.
    If the site is coded to Strict standards, taking it down to Transitional to allow for the target attribute doesn’t seem like a big deal to me.
    Option B is similar to coding for Transitional and including flash with the embed tag and ignoring the validation error, which i have done.
    I would probably go for C if validation is a huge issue. Otherwise, B.

  11. Tom Werner says:

    Using XHTML modularization, as mentioned by Keith H is the way to go, if you want to avoid javascript. And avoiding javascript for such essential tasks as linking to another page (be that in a new window or not) should be high on everyone’s list. By relying on javascript for essential actions, you are locking your audience into using a browser that supports it. Especially when a way already exists to use target in XHTML strict.
    Read all about XHTML Modularization from the W3C themselves.

  12. Jeremy Keith says:

    I would go with A. This what I’ve done in the past in this situation:

    <a href="" onclick="; return false">link text</a>

  13. Mike P. says:

    Tricky question, as the answer depends largely on the needs of the project, IMO.
    We tend to sell sites that validate, and therefore in most cases option C would be used.
    There’s really no big difference between the different levels of XHTML if you are delivering them as text/html anyway; going transitional should be acceptable.

  14. Definitely A. If I decide to follow the web standards, I follow them for real.
    MoeGreene: Putting some JavaScript in the XHTML markup is as bad practice as putting stylistic tag soup. Like we separate the content and presentation layers, we should separate the behaviour layer too. But of course, every body is free to choose the most practical approach for their projects and clients.
    Just my 0.02Euros

  15. BacMan says:

    I forgot to mention that in my solution (comment #1), javascript does not exist in the body of the document. If this function is not included or not called, links will open in the same window.

  16. kenrick says:

    Here is what I use, because at the end of the day, the client usually _does_not_care_ how it works as long as it works…

    I think trying to adhere to standards is a great ideal, but when it stalls a project I don’t think its worth it. In the production environment where I work, I don’t have the time or freedom sometimes. If I have a free moment, I might start researching common problems and solutions so that I can implement them in the future.

  17. Anonymous says:

    sorry it didnt get pasted
    <a href=”#” onclick=”, ‘popupwindow’, ‘width=400,height=300,scrollbars,resizable’); return false;”></a>

  18. Mark says:

    I agree with kenrick – as long as it works, the client *usually* doesn’t care about what you did to make it work.
    That said, I would go with C because there’s nothing wrong with using Transitional in place of Strict, and there are still some users who don’t browse with javascript enabled.

  19. Pedro Martinez says:

    I would do the following: Make the whole site XHTML 1 Strict compliant, then change everything to transitional and use Method C.
    Many popup blockers shutdown javascripts that open new windos.
    This way you have a document than in the future could be easily upgraded (using javascript or other possible solution) to XHTML 1 (if desired).

  20. Keith says:

    Hey all, lots of good responses here. This is actually a real world “problem” that I’ve got. The thing is that the biggest reason for new windows is to launch PDFs. To me Javascript for this seems like overkill.
    If you want to know what I’m leaning toward right now is C, much like Pedro explains it.
    I personally think A or C would be just fine, and it boils down to personal preference.

  21. James Craig says:

    Pedro, pop-up blockers only shutdown the method. If you have the script set up in an accessible manner (ie, using a valid href value) this is not a problem.
    HTML is for data.
    CSS is for style.
    JavaScript is for functionality.
    A: Strict doctype + JavaScript pop-up solution

  22. I would definitely choose A and use the code supplied by BacMan (#1). It isn’t really a question about Strict vs. Transitional XHTML. It is a question of separating structure/content and presentation. I cannot tell how many times that have helped my work. Having a “pure” XHTML body ensures flexibility when the site needs to be updated. On a large site, like intranets or B2B sites it is an essential requirement.
    Only A provides flexibility. B and C restricts your page to a certain presentational mode.

  23. Dante says:

    D: Don’t use XHTML at all.
    Seriously though even if I was silly enough to be using xHTML I’d go with B.
    It’s hard for me to say because I’ll never ever need to use XHTML.

  24. James Paden says:

    Most popup-blockers do not block popups that are initiated by a click from a user. They realize that the visitor wants to see this materal and let the popup go. Popup-blockers mainly block popups that are released onLoad and onUnload.
    Secondly, for commercial sites, I know my clients want those windows opening externally. That is a must. A visitor that leaves the site is a visitor who doesn’t buy something. External resources are fine as long as they’re linked to in a new window. That way the vistor comes back when they’re done (ideally).

  25. Frog says:

    As much as I would cringe doing so, my first instinct would be choice ‘B’.
    target="_new"> is in fact a basic function of HTML, not to be ignored. I wish it would validate properly. However, I really do want it to validate, and want to avoid Javascript code (clearly not neccesary – why complicate things?), so I would probably end up choosing C. Mainly because I use Transitional anyway. ^_^
    (Also, target=”_new” [as far as I know] won’t allow you to pop up the window w/ a size and attributes, so if you wanted that, choice A is your only way…)
    On the other hand, you may want to rethink your layout a bit and decide whether you want to give yourself that little extra bit to think about (pop-up blockers, what if users don’t notice, what happens on window resize, etc.) I’ve never really had to use a pop-up in my work. But that’s just me…

  26. Using a target attribute shouldn’t hurt in any doctype, but for the sake of standards, stick with transitional if you are going to use it.
    Using javascript could have its advantages over target, though, such as giving the opened window focus.

  27. “Using a target attribute shouldn’t hurt in any doctype.”
    Actually, it should. The target attribute is like the bgcolor attribute we used to have in the body tag. It is similar because it has no relation to the actual content – it is a behavior. We have XHTML for structuring, CSS for styling and Javascript (ECMAScript) for handling behaviors.
    What XHTML strict does is that it purifies this. Using Transitional is to me sort of the same as using table grids to layout your pages.

  28. ACJ says:

    For my personal projects, I don’t do pop-ups. Period. The behaviour of the hyper links is up to the user agent.
    If a client would insist on it, I would go for method A in case we were using XHTML1.0 Strict or XHTML1.1. If we would be using HTML4.01 (I don’t do XHTML1.0 Transitional anymore… it’s either HTML or xml for me, nothing in between), I’d be using target= simply because it’s allowed in HTML and it would be silly to write extra behavious scripts for it.
    By the way, there’s also the option of adding the attribute to the DTD. After all, it’s an eXtensible markup language. :)

  29. eric says:

    “D: Don’t use XHTML at all.
    “Seriously though even if I was silly enough to be using xHTML I’d go with B.
    “It’s hard for me to say because I’ll never ever need to use XHTML.”
    The differences between XHTML1.0/Transitional and HTML 4.01/Transitional are minimal… there’s really no reason not to use XHTML. If you do, your pages will work for sure in the future. Read through Zeldman’s DWWS if you want to understand the real meaning behind XHTML.

  30. Anonymous Coward says:

    Pardon my ignorance, but what’s the rationale behind deprecating “target”? It’s simple, it works well, and there’s no need to resort to scripting to do something so blindingly obvious. Every website needs to open new windows at some point (usually to load non-HTML documents). I shudder to think of the legions of “web designers” who are not trained in coding screwing up the javascript (no offense meant to the crowd reading this).
    One may argue that behaviour should be separated from style, but embedding javascript in the hyperlinks is *not* separation of behaviour from content, because you can’t easily go back and mark the links as “new window” or “same window” or “new small window at 300×200 pixels” as we can do now with CSS for style, and have the behaviour change appropriately.

  31. Anonymous says:

    Use a dash of *.js file and some sprinkle of class and voila…
    Lorem ipsum <a href=”” class=”popup”>dolor</a>
    More details:

  32. Sverrir says:

    Hmmm, somehow I list myself in the previous comment ;)

  33. ACJ says:

    @ Anonymous Coward
    Personally, I never open a new window. I do, however, open alot of new tabs. This is my preference. If your preference is to open new windows, by all means, please do, but please don’t force your preferences on my webexperience.
    In a nutshell, that’s what it comes down to.

  34. “Using Transitional is to me sort of the same as using table grids to layout your pages.”
    I’d have to strongly disagree there, Thomas. I’d say it has nothing to do with using table-based layouts. Gigantic gains can be had in moving toward structured markup, whether it’s Transitional, Strict or even 4.01.

  35. Tom Werner says:

    XHTML doesn’t deprecate target, it merely moves it out of the standard four modules that make up the base XHTML DTD, and into the “xhtml-target-1″ module. Specifically it allows you to use target on <a>, <area>, <link>, <form>, and <base> elements.
    If you wish to use target in your XHTML, then you create a DTD file that states what modules you are using, and then specify that at the top of your XHTML pages. It’ll validate and everything!
    There’s an article coutesy of Zeldman that covers this.
    Still dubious? Go look at the W3C’s Documentation on the matter.

  36. Tom – Good info. While I had seen several sources say that target was deprecated, I couldn’t find anything definitive at the W3C. That must be why.
    I’m also intrigued by Jeffrey’s concluding sentence:
    “Rather than open these multiple cans of worms, we still advise designers who want to open new windows via the target attribute to use XHTML 1.0 Transitional.”
    I tend to agree. The can of worms he’s speaking of has to do with whether creating your own DTD will throw certain browsers into Quirks mode. Seems like a lot of trouble to just pop a new window — but I love the concept of it all.

  37. Tom Werner says:

    Dan -
    I tend to agree. I use XHTML 1.0 Transitional for exactly such reasons. I can at least expect modern browsers to handle it reasonably, but move to strict, and things get a little crazy. Hopefully it won’t be too long before we can actually start serving our XHTML pages with an XML mime type, and follow the W3C’s rules without suffering the effects of browser misbehavior. When that time comes, It’ll be XHTML Strict all the way!

  38. Keith says:

    AC (#33) — Not launching a PDF in a new window (the root of the problem for me) is a serious usability no-no (especially for people on IE with no tabs) as people are so used to having them open a new window they expect it to do so, when it doesn’t they often close their browser. Not fun.
    It’s a fact — I’ve seen it many, many times and done it many more. But you might not be thinking about PDFs.
    The only time I ever would use a pop up (aside from special cases where I would implicitly let the user know what is going on, like the music player on my site) is for something like a PDF or image.
    I get the feeling that A is probably the best way to do this. Having said that I’m still going with C. It’s just more practical in my situation. I imagine I’ll use A in the future where it makes sense to do so.

  39. Keith H. says:

    I also alluded to the DTD method, but I referenced an Accessify article. I completely understand your point about the hodge podge of DTD’s, but I am curious. If the move is towards XML, then why should this be an issue? I mean theoretically using XML you have the ability to create your own DTD and as long as your documents are valid, and well formed everything is kosher. I am playing the devil’s advocate here a little bit because I agree with you, but I am curious as to your opinions on this.

  40. mac says:

    C works best for me

  41. Tom Werner says:

    I don’t think there’s anything hodge podgy about it. The modularization was introduced specifically so that web designers could select and validate against the pieces of XHTML they needed. So if you need target, you merely create the necessary DTD, and you’re set. This is not a hack or workaround, but the recommended way to do things.
    The modularization is very powerful in that it allows for standards compliant extensibility of XHTML. The W3C (or others) can create and release new DTD Modules, and by including those modules in our own DTDs and validating against them, we ensure that we remain in compliance with those standards.
    Here’s how the W3C Puts it:
    “Modularizing XHTML provides a means for product designers to specify which elements are supported by a device using standard building blocks and standard methods for specifying which building blocks are used. These modules serve as “points of conformance” for the content community. The content community can now target the installed base that supports a certain collection of modules, rather than worry about the installed base that supports this or that permutation of XHTML elements. The use of standards is critical for modularized XHTML to be successful on a large scale. It is not economically feasible for content developers to tailor content to each and every permutation of XHTML elements. By specifying a standard, either software processes can autonomously tailor content to a device, or the device can automatically load the software required to process a module.”
    The only reason I see not to use XHTML 1.1 Strict with a Hybrid Document Type right this second is the shoddy browser support for it. And that’s an awefully big reason.

  42. Alistair says:

    Option B doesn’t seem to be a viable option period. If you take the time to make your document validate, why would you then use a target attribute and break it? Seems counter-intuitive to me.
    The solution would be either A or C.
    I personally go for option A with a href value filled in. That way, it degrades well even if they have Javascript disabled, they just don’t get the new window. The world won’t end, that’s what a back button was invented for.
    If you don’t want to use Javascript for your popups, then option C would seem logical. Mark it up as strict as possible, barring the use of your target attribute; surely everyone would be happy then?

  43. Kris says:

    I would choose option A, after of course carefully considering the need for a popup in the first place.
    As a sidenote, there is no harm in switching to Tranisitional Doctype and still using Strict constructs (like block-elements in blockquotes, etcetera). That you ‘downgrade’ to Transitional does not mean that the integrity of your markup has to suffer. If you however ‘upgrade’ to Strict but cannot let go of deprecated markup, then your pages do suffer (option B).

  44. Tero says:

    How about using classes to identify external links? This is very similar to BacMan’s solution:
    classExternal = /\bext\b/;
    function externalLinks() {
      for ( x = 0; x < document.links.length; x++ ) {
        if ( classExternal.exec(document.links[x].className) ) {
    window.onload = externalLinks;

    This way, there is no Javascript in the HTML. The links that should open in a new window, are marked with
    <a href=".." class="ext">.
    And, with the class definition, you can also make the external links look different from normal links in your CSS.

  45. On a side note : I’ve never forced the users to view the PDFs in their browsers, but made them download them ( by sending the files as octet/stream ) which is way more convenient.

  46. Al Abut says:

    Dan/Keith/Tom, about XHTML modularization;
    Dan said: “The can of worms he’s speaking of has to do with whether creating your own DTD will throw certain browsers into Quirks mode.”
    And Tom said: “The only reason I see not to use XHTML 1.1 Strict with a Hybrid Document Type right this second is the shoddy browser support for it.”
    This is fascinating – I saw the same article recently as well and have been mulling over using the technique. Anyone know of any specifics on browser support for modularization out there, something as easy to understand as Eric Meyer’s old CSS support charts? A word or two on real world consequences would be sweet.
    I’d be inclined to go down this route even if it possibly had Quirks mode ramifications (even if it didn’t open a new window, the link would still work since it’s not messing with the href attribute, right?) and bank on future browsers getting it right. I’ve made DTDs for XML before (for stuff that had nothing to do with HTML) and it was kind of fun in a twisted way once you got used to it, making up your own vocabulary of tags and explaining how they should be used. Look at me, I’m a mini-W3C! Making up whatever new elements I want, woo hoo! That’s how I felt when I first started working XML. Whipping up whatever tags I wanted to mark up the content with – man, the power went straight to my head. Imagine if we could do that in web browsers as well and have them actually understand our kooky homegrown verbiage. Whoa, got carried away there.
    Well, for now, I guess you can feel the combination of the XMLey goodness of homegrown markup and long reach of browsers in two ways: send an XML file to a Flash movie to have it do whatever it is you’d like the all-dancing, all-seeing Flash monster do, or send some XSLTs and XML to browsers that can make XHTML on the fly.

  47. I’m still a fan of the method guis posted above – I pilfered the code from Movable Type’s templates, and it works nicely.

  48. The answer A (JavaScript solution) could be the correct approach for me, but some conditions must be satisfied:
    The href value must be the real URL.
    New browser windows should be opened only if it is really needed (eg: links to other sites).
    The title attribute must always be used and specify that the link will open in a new window.
    In case you are linking other types of document (eg: PDF or MS Word documents) the title attribute should be used also to indicate if the URL is not an HTML page, and in this case there should be also a download option.
    The new window should always be a full featured one: with menubar, toolbar, location, scrollbar and resizable, just like the target=”_blank” solutions.
    The JavaScript solution suggested, more then one year ago, on Accessify is accessible and usable, and I don’t see any drawback.
    Instead choosing a Transitional Doctype means using deprecated tags and attributes, while these can be avoided.

  49. Dan, I’d have to strongly disagree there, Thomas. I’d say it has nothing to do with using table-based layouts. Gigantic gains can be had in moving toward structured markup, whether it’s Transitional, Strict or even 4.01.
    Yes, indeed – I totally agree. But when I wrote that XHTML Transitional was like using table-based HTML it was in a different context.
    One thing is to have structured markup, which we agree is extremely useful and important. In structured markup we create our code so that a headline, paragraph, links etc. are explicitly structured within their tags (as you of course know). And here the question of having “target” attributes does not change the correctness of structured markup – thus your disagreement with me is fully correct, I would also disagree with me :)
    But, another thing is to have separated markup/code – for me an equally important element to make XHTML – and what I was referring to in my previous comment. Separated markup/code is where you separate your structured markup, the behaviors and the style. It basically allows you to adjust any one of these three independently and give you full flexibility. Want to open all your sidebar links in a new window? Change your behavior file. Want to make them blue? Change your style file. Undo it all? Change them again. No need to adjust every individual page on your site.
    When we are talking about separated markup, we cannot have “target” attributes – just as we cannot have “style” attributes (style=”color: red”) – because we would then loose the separation and start mixing the code. When we look at a table-based page, we have no separation. The content is mixed together in a soup of tags, behaviors and style. When most people choose transitional over strict, it is, again, because they whish to mix the markup instead of separating it. In this case we are adding behaviors to our links.
    It is in this context I compared table-based HTML with Transitional XHTML.
    Al Abut, “Imagine if we could do that [using XML/XSL] in web browsers as well and have them actually understand our kooky homegrown verbiage. Whoa, got carried away there.”
    Ahh, but you can. What you do is instead of having the client but together the output you move this process to the server. I am doing this on my site. Every page is build up by an XML file for the content, a global template for navigation, a global XSL file to transform it and a global CSS file for the style. This is then all put together, server-side, when a reader requests a page.

  50. lolly says:

    Answer D: Let the user decide. Or failing that, A.

  51. compywhiz7 says:

    I agree with lolly. New windows really shouldn’t be opened, and if they must, use JavaScript, since it is strict-compliant functionality.

  52. jgraham says:

    > The differences between XHTML1.0/Transitional and HTML 4.01/Transitional are minimal… there’s really no reason not to use XHTML
    Well, if you ignore the fact that XHTML 1.0 SHOULD be served as application/xhtml+xml to compliant user agents and MAY be served as text/html to non-complant UAs. That means that almost everyone who is using XHTML in the way recommended by Zeldman (i.e. without doing any of the hard stuff) is already violating the spirit of the spec in a more serious way than using Transtional rather than Strict too get their target attrbute back.
    HTML 4 is just as forward compatible as XHTML 1.0 in the sense that one can automatically convert a vald HTML 4 document into an equivalent valid XHTML 1 document but neither can be automatically converted into a valid XHTML 2 document. If you’re not planning to go to all the effort of ensuring your markup is valid forever, and you’re not willing to send your document with the correct MIME type, you shouldn’t be using XHTML at all, you should be using HTML 4.01 Strict.
    Now, as for the real issue at hand, there seems to be a general feeling that the javascript solution is the best approach. From the pont of view of an end user, the big disadvantage of this approach is that I can’t turn it off. If you use the target attrbute, then I can set browser.block.target_new_window=true and be rid of your unwanted popups forever. If you use javascript, it’s much harder to turn off without blocking potentially useful scripts.
    In other news, PDF readers which insist on opening up in my browser windows are the bane of my life. I can only imagine the person who came up with that idea had never actually used a web browser.

  53. Shaun Inman says:

    A lot has been said but there are one or two things left to note. BacMan’s function requires that all external links contain the `rel` attribute set to “external” (but the function could also be extended to account for something like `rel=”download”`). I don’t think that was mentioned.
    I don’t think basing the application of target on a className as suggested by Tero is the way to go when the more semantic relationship implied by `rel` is available. Option A using a technique similar to BacMan’s is my choice.
    The other big thing to note is that `target=”new”` and `target=”_blank”` are two completely different things.
    `target=”new”` looks for a window or frame named “new” and if it exists loads the link into. If it doesn’t exist then a new window is created with the arbitrary name of “new”. In this case the value “new” could be any string except “_self”,”_top”,”_parent”, and “_blank” (which have special behaviors) and it would behave the same way.
    On the other hand, `target=”_blank”` will create a new, unnamed window every time. We should all be aware that there’s a huge difference in their behavior that is overlooked in the questions example and answer choices.

  54. Andre says:

    Why is it that everyone has to open new windows? Hello! We are talking about my memory here and if it comes to that, I prefer to have it at MY command. After all, every new instance of Firefox e.g. takes up another 20M of memory.
    So better stick to method D “Don’t use pop-ups” (see #50). It works perfectly, no matter what you want to do. As for PDFs (#20), it is a fact that the back-button is the single most-used feature in a web browser. So what’s the use of a new window?

  55. A is the definitive one, with class-abuse approach.
    <a href="url" class="wndopener">highlight</a>
    Then, on page onload, collect all those links using xGetElementsByClassName and you're all set and ready.
    I totally abuse this technique as I'm using it to pass arguments to
    onclick (or any other) handlers by setting them as multiple dummy classes.
    Seems to work pretty well.

  56. Neither one or another. I’d extend the xHTML module.
    Something like Eva done in
    More documentation about it on

  57. waylman says:

    I would have to go with C, or A as long as the link is kept accesable. In other words, A is only good if the link still works (usually opening in the current window) when the user has javascript disabled.
    I would like to say D, but the CSS3 Hyperlink Presentation Module is only a first working draft for CSS3. As I mentioned in my weblog back in February, we still have to wait for it to become a recommendation and then for updated browsers that support it.
    Until then, I’ll try to stay with C and only use an accessable variation of A when absolutely necessary.

  58. Keith H. says:

    Thanks for the clarification. I read the article, but I did not read the actual specs in any detail. So once again it seems that developers are constrained by browser makers. I have a dream. A dream that someday, all browsers will fully support W3C specifications. A dream that web designers will be able to write code without hacks and…..
    Ok, maybe that was a little over the top.

  59. Vladamir says:

    A, as some have already pointed out, Popping a new window is a behaviour, not structure and definitly not style, and should be on its very own behaviour layer ( a linked *.js file ). The <a> should be coded like a normal link:

    Click Me

    Using an “id”, i think, is a better way of accessing the tag than using a class name
    Then in the bahaviour script, attach a popup method to the tag like this:

    document.getElementById("FooBarLink").onlick = PopupURL(document.getElementById("FooBarLink").href);

    PopupURL is a method that will simple launch a new window using the link “href” value.
    If you have javascript on, it will popup a new window.
    If you have javascript off, it will behave like a normal like.
    If you right click and open in new tab/window, it will do it without complaining.
    You could also provide a button on the site that allow a user to switch off the popup script?
    However, i don’t really see the point in me going on about this, check out this article on alistapart for a better idea of what i’m going on about.

  60. Vladamir says:

    Sorry, my typing is too used to intellisense!
    The Click Me Link should look like this:
    <a id=”FooBarLink” href=”foobar.html” >Click Me</a>
    oh, and the javascript property onlick isn’t a joke, its my typing. it should be onclick

  61. Aaron Gustafson says:

    I would use something akin to BacMan’s solution but add in an additional line of code to create a title with (or append to the title) the text “(this link will open in a new window)”. This is keeping in line with the WCAG recommendations to alert users if a new window will be openned (and focus will be changed).

  62. I’ll take “C” Dan.
    No sense adding javascript bloat just so you can pound your chest and proclaim “Me, Strict!”
    For real-world application, Transitional is totally acceptable. Going Strict for the sake of going Strict is a total nerd-langer thing to do.

  63. Luke Redpath says:

    Definately A.
    Josh, using javascript is NOT bloat, it’s purpose is to add functionality and behaviour to your pages.
    The whole web standards movement focuses on separating style/presentation from structure. XHTML is for structure and you should use CSS for presentation – this has been reiterated time and time again – but it should also be made clear that its not for behvaiour either – this should be done with script.
    Of course, your page should not *rely* on script for accessibility reasons. Hence, the best solution IMHO is:
    <a href=”mylink.htm” rel=”external”>
    Then a piece of javascript that goes through all links with rel=”external” in the code and attaches an event handler and window opening script of your choice. No onclicks should be used in the XHTML. This is the true separation of behaviour from structure.
    No “bloat” is added as your XHTML isn’t full of event handlers, just a rel attribute on external links. The links still work in browsers without javascript enabled, and finally, you can still right click on the link and do what you want with it (open in new tab for example) like normal links.
    If its true separation you are after (and this should be the ultimate goal) then this (or variations on the above) should be the only way. I choose to use rel instead of class as it makes more semantic sense.
    Finally, if you are still happy to use Transitional, then there is absolutely nothing wrong with C. B is a no-no.

  64. Luke Redpath says:

    Also, I find it slightly concerning that people would go as far as creating their own custom doctype just so they can use the target attribute.
    Being able to create your own doctypes is a great feature – however – doing it just so you can use a deprecated attribute (one that was deprecated for a reason) whilst still having your document validate seems completley and utterly pointless to me. It is like saying “well, I’m not happy with such and such standard, so I’ll modify it and create my own ‘standard’”. Surely missing the point of standards altogether?
    If you are willing to do the above, you might as well just use XHTML Strict, use the target attribute, and let it remain invalid. It amounts to the same thing IMHO.

  65. Tom says:

    I’m sure it’s fun to argue the finer points of XHTML modules. However, there’s work to be done! C all the way.
    Personally, I love xHTML, CSS and standards to the bone. But I’m NOT going to write custom DTDs, and I’m not going to worry about one validation error when my deadline is tomorrow at 8 AM.
    I’ve said it before, I’ll say it again: We can’t be “standards lemmings” and follow this over a cliff.

  66. Vladamir says:

    Bloat Code, What Planet are you On. Hangon, during the dark ages everyone used <Font> tags to mark up style infomation. Then along came css, seperated structure from style and everyone bowed down to the w3c for this act of magic. for, by only needing 1 line of code, every paragraph on the page could be styled the same. And because this code was seperate from the structure, it only had to be downloaded once!
    Using javascript as behaviour layer, this does exactly the same thing by simpling the structure and behaviour, Again, one simple bit of code magically makes all your rel=”external” links popup a new window. Now please how could possibly proclaim that a modern use of javascript is bloat code, i want a fight here, what is your response Josh

  67. Rob Cameron says:

    If you’re all for Standards, then you’re all for separating presentation from structure. And if you’re for that, you should also be for separating behavior, which means no target= in your links.
    I think the method mentioned by Vladamir (and the A List Apart article he links to) is the most elegant solution I’ve seen so far — works for left-clicking, right-clicking, with or without Javascript enabled.
    Vladamir’s Post

  68. Vladamir says:

    Again, i appologis for my crap spelling and grammer

  69. Anonymous says:

    C it is just the easyest way.

  70. Tom says:

    Tom, I understand in the real world you need to get things done right away. But nobody is suggesting you write your own external link script. There are plenty of good ones linked to throughout these comments. Stick one in an external js file, better still, build up your own library of commonly used functions which you can link to in your html pages with ONE line of code, add rel=”external” to your external links instead of target=”_blank” and you are done.
    It’s not hard work, it’s not gonna get in the way of deadlines and you aren’t being a “standards lemming” just by doing the above. It just makes good sense.

  71. Luke says:

    Sorry, that post above was me, not TOM. I must have written his name in the name field by mistake. My bad.

  72. Vladamir says:

    For those Javascript kiddies out there, here’s an excellent article about seperating structure and behaviour by Peter-Paul Koch.

  73. Jason says:

    I think a more simple solution to this particular problem is to modify your web server so that it sends the PDF files as an attachment instead of inline, with a header akin to this:
    Content-Disposition: attachment; filename=filename.pdf
    You would have to do testing of your own on this, but in my local tests this caused the browser to always bring up the save/open dialog. When the user selects open it should load the external acrobat reader not the browser plug in.

  74. David House says:

    How about avoiding these situations like the plague?

  75. Bruce says:

    E) Ask yourself if you really need to open the link in a new window. Then if so, provide two links, a textual link which opens in the same window, followed by an icon which opens in a new window using JS in an external file similar to what #1 BacMan posted.

  76. Sam Parsons says:

    In an ideal world we should minimize popups and let consumers choose to open links in seperate windows if the so desire. However, it’s not a perfect world, and many uers and not that tech-savvy. So pop-up’s must stay. I would choose option A because it makes the most sense as long as the actual link is left in the href=”" and the JavaScript is kept externally so it’s reusable and quickly modifiable too. So A for me.

  77. “I’m also intrigued by Jeffrey’s concluding sentence: ‘Rather than open these multiple cans of worms, we still advise designers who want to open new windows via the target attribute to use XHTML 1.0 Transitional.’
    I tend to agree.”
    Dan, he was also referring to the “can of worms” opened by trying to serve your documents with the correct MIME type.
    As to whether you should be worried that browsers will resort to Quirks Mode if the DOCTYPE isn’t familiar, I wouldn’t worry. I’ve thrown up a few tests that suggest that the DOCTYPE sniffing algorithms are a bit smarter than that: 1) An XHTML 1.1 document that uses Jacques Distler’s DTD. Opera 7, Internet Explorer 6, and Mozilla 1.7 each have no problem rendering this document in Standards Mode; 2) An XHTML 1.1 document extended via an internal subset of the DOCTYPE declaration. Rendered in Standards Mode by Opera 7, Internet Explorer 6, and Mozilla 1.7; and 3) An XHTML 1.0 Strict document extended via an internal subset of the DOCTYPE declaration. Also rendered in Standards Mode by Opera 7, Internet Explorer 6, and Mozilla 1.7.
    Extending via an external subset of the declaration is convenient (since you don’t have to create your own DTD), but leaves a short string of characters at the top of pages served as text/html. Documents served as application/xhtml+xml do not have this problem.
    The test documents above are served as text/html for two reasons:
    1) Mozilla always renders properly-served XML in Standards Mode; and 2) Internet Explorer can’t render XML documents served properly.
    I’ve yet to see any reason to believe that the DOCTYPE sniffers employed by the major browsers aren’t smart enough to get extensions. I can understand why Zeldman might be worried, but it just doesn’t seem to be the case.

  78. Guilherme says:

    I take (A) with eventListner saving the XHTML code.

  79. David says:

    None of the above. I have in fact gone over this problem myself, specifically to open all offsite links in new windows. I solved it by marking all offsite links with rel=”external” and using javascript to find all such marked links and set a target on them (just because it’s not in XHTML doesn’t mean it’s not in the DOM). I’ve got an article written on my method:

  80. Jim says:

    This seems to be one of the hot topics of the week. I just converted to 1.0 Strict using the rel=external javascript solution for new windows. I have to admit I thought the target attribute was completely deprecated. It appears that a lot of us need to gen up more on the modularization of xhtml. I have not given this much consideration until now.

  81. Jeff Minard says:

    I can not believe that in 80 posts not one person has mentioned this:
    target-new property
    Of course, doesn’t work in anything yet (that I know of) but, I can still dream.
    Back to reality, i’d go with A and use class abuse to add the pop-up links.

  82. There’s more of what I had to say above over at my site. There’s a lot of overlap, but there’s some new stuff and a lot more links to related resources, if you’re interested. I think the blog entry more clearly makes the case for extending XHTML.

  83. Micah says:

    To the folks worried about having to write personalized DTDs: I don’t think the point of XHTML modularization is to have each web designer write his own DTD, I think the idea is to allow other bodies to create standard DTDs for people to adopt. For example, Amazon could write a custom DTD for marking up data on books, and book enthusiasts across the web could link to Amazon’s DTD. Even the W3C itself could write a small DTD defining the target attribute and allow people to link to that. It’s probably just a matter of time before this process becomes commonplace and a natural tool for any XHTML newb (and hopefully vets too).

  84. Dan Jallits says:

    I believe the end-user should be in total control of their own experience. Take the following in consideration; if a user likes having multiple browser windows open or even tabs, then they will know how to perform the necessary tasks. Therefore, my vote goes to the Strict DTD, this way I do not need to change my DTD declaration, I am still legit with validation, and the user has full control of their browser.

  85. Rob Reed says:

    In the UK, 2 conclusions from a recent web accessibility survey (#1) stated:
    The following WAI Guidlines need to have more emphasis:
    - avoid pop ups & new windows without informing the user
    - identify the target of each link
    (#1) Diability Rights Commission – Access and Inclusion for Disabled People
    Granted new windows/tabs are required sometimes (transactions/disclaimers etc), but why not include a menu/way back to your site (as well as Back button anyway) at the head of the PDF.
    Wow >80 comments – I think I’m save in assuming that no-one will read this.

  86. jgraham says:

    Just to emphasise that last point:
    “10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]
    For example, in HTML, avoid using a frame whose target is a new window.”
    Since the majority of user agents do not allow you to turn off new windows created with javascript, using javascript to open new windows automatically means that your site fails a level 2 accessbility checkpoint (the same level of accessibility checkpoint you fail a for using font tags). If you choose to go with some target solution, you’re doing marginally better as it’s much easier to find browsers that allow people to ignore target attributes. Even then, you fail the accessbility checkpoint since many browsers do not offer a way to turn this behavior off.

  87. Phoat says:

    I believe there is a thin line as far as what events should be considered behaviors and what presentation. The pseudo-class :hover is an example of this. In reality, when you hover over an element, you trigger an event to occur, yet this “behavior” is defined in CSS.
    A lot of people have been saying that A is the best solution because it seperates behavior from presentation. Using that same logic, one would have to conclude that to change the color of links, the best solution would be to use XHTML to define the link and JavaScript to change the color when it is hovered.
    In essence then, W3C is breaking its own rules when it says you must seperate content from presentation from behavior because :hover is almost certainly a behavior.
    :hover, however, IMHO, is included in CSS out of pure convenience, just like being able to define the behavior of certain links with CSS3 using target-new as Jeff Minard mentioned above.
    Remember, we are all working with the technology and standards that are available to us now. If we have to break a few presentational rules to get the results we need, (by including a target attribute to links) so be it.
    So for me, I think that the best solution is C for now, and when CSS3 is fully supported (yeah right), XHTML 1.1 strict with CSS for the way popups are handled.

  88. Phoat says:

    And one more thing. I don’t really believe anyone MUST design using XHTML 1.1 Strict. You can just as easily get the same results using a transitional doctype and avoid all the problems that comes with being bleeding edge when working on client projects. On personal projects, anyone can do what they want, but when working for money, I seriously think it is a waste of your resources trying to solve a problem when a solution exists by taking a small step backwards.
    I know that a lot of you will start to talk about forward compatibility, etc, but… noone has considered what will happen to our jobs if sites don’t need to be tweaked and optimized every now and again :P

  89. Phoat says:

    OK OK OK… a friend of mine pointed out the stupidity of my first post… Sorry guys.
    Fact of the matter is, the browser defines the state of all the elements when the mouse is hovering over it, CSS is used to define the style of that STATE of the element. Sorry if i caused confusion.
    Despite this, I still stand by my original argument. I could easily argue that you would then be presenting certain links differently than others by making them pop up in new windows, therefore allowing for a CSS3 solution.

  90. Ed says:

    I’d have to say option C; moving to traditional. Opening things in new windows isn’t a good thing to do as a standard practice.
    Just because a device is XHTML compliant, doesn’t mean it will have JavaScript support. If you’re designing purely for the web this isn’t a problem, but XHTML allows us to design for many applications including portable non-JavaScript devices.

  91. Eric TF Bat says:

    Yep, I figured this would turn into a discussion of the evils of opening separate windows. It’s a bit like that ALA article about how to use CSS with HTML emails, where all the discussion was saying that if you ever use HTML email your hair will fall out and your dog will bite you. Seems a bit like people are missing the point: some people DO want to do this. Certainly they should think twice before doing so, but if after thinking about it they decide it’s still worthwhile, then good on them. If you assume they’re too stupid to understand why they should think twice, then you’re being arrogant.
    I only use popups for two things on my personal site:
    The first is my “report a problem with this page” button, which appears on every page. You click the button and you get a separate window with one textarea and a submit button. If you type something and click submit, I get an email with the URL you were just looking at and your comments. It’s simple enough that anyone can do it, anonymously or not, and people do. It’s the ideal testing method, and I recommend it to anyone and everyone; feel free to steal the icon too – it’s public domain, and consistency is always good.
    The second is a bit of info on the wiki-like markup language I use. If you’re making a comment on one of my blogs, you can click the link and get a cheatsheet on how to add in some extra formatting.
    In both cases, the windows are throw-aways. Click ‘em, read ‘em, close ‘em down. They shouldn’t get in the way of the standard process of using my site. They should be offshoots, easily discarded. You can Ctrl-Click in Moz and get them to appear on a tab, or just click in any browser and see them in their own window. It’s how I mean it to work, and it works, and that’s good enough for me.

  92. Faruk Ates says:

    I just have to say, I was rather shocked to see it took almost 60 posts before someone would mention the A List Apart article on Accessible Pop-up Links!
    When I read that (still recent) article, I was overjoyed, thinking `finally we have the answer to using pop-up links properly!`
    They work with javascript disabled without making a mess, and they work very smoothly with javascript enabled, which most people have (by far).
    ALA’s method is exactly how I will be implementing the Help pop-up windows for my current project. And I’m not even using a Strict doctype! Wasn’t it officially recommended that websites use XHTML 1.1 Transitional anyway?

  93. Kim Siever says:

    I would say a version of A. I try to use:
    <a href="mypage.html" onclick="'mypage.html'); return false;" onkeypress="'mypage.html'); return false;">Link</a>
    It allows non-JavaScript users to still acess the page. It also allows users not using a mouse to access the page.

  94. Kim Siever says:

    Oh, I forgot to mention, that where possible, I try to avoid opening new windows at all. Most of the ones I use are with third party content sites like HaloScan that do it by default.

  95. Brett Morgan says:

    I find sites deciding that they are going to popup a new window incredibly annoying. It isn’t what I expect, it is not what I want.
    It is a real case of a website deciding that I am stupid, and must be controlled. I usually stop using a site as soon as it does this to me.

  96. Dante says:

    Target is indeed very useful. You need it for frames and popups, which can be deadly but powerful if used correctly, see to see what I mean.
    XHTML 1.1 Strict is quickly becoming some sort of a manly thing to show off. “Hey look! My markup is more [unnecessarily] strict and valid than yours. You’re still using XHTML Transitional? Loser!”.
    To me XHTML 1.1 Strict == useless, but that’s just my opinion.
    So again I say “B” because if that kind of validation error occurs, the browser won’t crash or explode (though Mozilla, cuz it’s so standards compliant, will probably want to).
    There is absolutely no reason at all to remove target from any doctype, because even if frames and popups disappear, you can still use something like target to seperate behaviour and structure.
    Example: you want all h3′s to be replaced by images via W3C DOM (Javascript). In the script you say
    if (h3s[i].target) replace()
    which means “this h3 has a target, therefore it should be replaced”.
    Or all links with a target have to return false (for like a JS img gallery). The script will make any a tag with a target return false, and not follow the href.
    My Two cents.

  97. Michael Brown says:

    The CSS3 Hyperlink Presentation Module deals with this, allowing us to open new windows and tabs in front, above, behind, back etc. all through CSS. Very powerful if you think about it…

  98. Vladamir says:

    I have noticed some people suggest ‘A’, then use Javscript to iterate through each external link and then use the DOM to add/change the target attribute to each link. Is this correct? It is my understanding that the specification for the element would exist in the dtd for the document, i.e. XHTML Strict 1.0, not the DOM. The DOM (Document Obect Model) is simply a way of interacting with a document by providing access to Element Attributes/Properties (this.href = "me.html";) as well as methods (this.onclick = go();) for doing things with the document elements.
    This does bring up an interesting problem, why is it possible to add/change these Attributes if they are not allowed in the document? Is it a flaw in the XHTML Specification, The DOM or at the browser level? I must admit to not having tested this and would be greatful to anyone willing to shed some light on this.

  99. liorean says:

    Well, I personally think that you shouldn’t ever open links in new windows from a document. The document is clearly separate from the interface, and windows are interface components.

    However, I also realise that there might be a benefit to doing this, especially in a real world situation. I would personally go for the solution of using XHTML1.0 strict, and for each link with an ‘http://’ part insert event handlers to open a new window, or if I wanted to open internal pages in new windows simply use the class or rel attrbute to signify that and use the same method of making them open in new windows. Preferably though, I would add a ‘hint’ that the user might want to open the link in a new window, and leave the choice of doing so up to the user.

    In XML, there are clearly defined ways of doing this. XLink provides the following syntax for instance:


    I personally see very little use in not using the powerful capabilities of XLink, so if one really wanted a popup, and had a situation where XML and XLink is an option (not likely now, but let’s say ten years in the future, if I allow myself to be optimistic) then this would be my preferred choice. [CSS3Hyperlinks] might be another future solution for it.

    However, to reiterate my standpoint in the first paragraph of this comment, I really think XLink and [CSS3Hyperlinks] should stay well away from the user interface. The user interface should be entirely under the control of the user, and you should have to ask the user first if you want to access it, similar to how you have to ask the user for universalbrowserread to get out-of-domain access from JavaScript in Mozilla.

    Oh well, enough ranting without reading through the other comments here. I’ll answer Vlad’s question for a change:

    Browsers operate on the assumption that a document is a HTML document. They recognise it much akin to how the later created namespace associations work – all HTML documents are part of a wider-spanning set of elements and attributes to which certain behaviors and renderings are attached. They are not DTD specific, they are content type specific, and match that to their internal proprietary recognition mechanism. So, they work on a more general level than the limited one set by the DTD.

  100. Al Abut says:

    No, no, I have to chip in with this – I don’t want people to get the wrong impression about using Strict vs Transitional just because no one threw in a rational counter point. Strict is not, I repeat not just to show off and do the markup version of Flashturbation. There is a great practical reason to trigger Standards mode instead of Quirks:
    The Standards mode rendering engine displays content on-screen way way faster than Quirks mode, making the site feel more responsive and download-friendly. It’s called “perceived usability” and fast screen rendering increases this.
    Modern browsers are actually several different browsers packaged and hidden under one skin – an old Quirks mode one that’s basically the ghost of NN4 on life support, and a blast from the future, a tiny, lean, super fast rendering engine in Strict mode. Tiny because valid xml files are structurally oh so simple – it’s the whole point of xml and xhtml! Oh, and just declaring it Strict doesn’t make it so, just like wearing pink pumps doesn’t make me a pretty girl. If you use the Strict doctype but don’t validate, throwing the browser an error, it bitch slaps you back to Quirks mode and starts rendering from the top again, just like you rightly deserve.
    It’s a shame that a lot of standards nazis are pushing Strict out of ignorance and pitching it simply as the Right Thing To Do when they really mean Be Cool Like Us. That’s idiotic and it’s too bad that people are getting the impression that groupthink is the only reason to care about validating strict markup. Now that education about web standards has turned the corner and has been mainstream knowledge amongst web developers for quite a while now, the pool of eloquent activists has been seriously diluted. There’s only so many Zeldmans we can clone to stem the tide, I guess…
    Back on topic, I vote for XHTML 1.0 Strict with modularization to add the target attribute, so that modern browsers will open the links in new windows and ancient ones will open it in the same window, avoiding javascript hacks altogether.
    A more detailed write-up on the issue is at the clagnut site.

  101. Dante says:

    ‘Standards Nazis’ is a phrase I intend to use a lot from now on.
    I choose Quirks Mode simply because when IE 6 goes into Strict Mode, and uses the CSS1 Box Model (which I think is silly), and there is no (pure CSS) solution to make IE 6 use the ‘border-box’ model.
    Please define ‘Javascript hacks’. If you’re talking about a script like this:

    function init() {
    if (!document.getElementsByTagName) return;
    var x = document.getElementsByTagName("a");
    for (var i=0;i
    That is not a hack but a way of increasing usability without sacraficing accessiblity.
    Quirks Mode = Slower than strict?
    Sure. And the US really went to the moon, too.

  102. Etienne D says:

    Hy guys,
    I’ve read all the 102 comments and nowhere I found this idea : why not create a JavaScript which is able to determine if the link has something to do with your website or refer to an external link.
    For example :
    Link a a href="" or Link b a href="/blog.html" will always be loaded on the same page whereas Link c a href="" will be loaded in a new window.
    The script only have to check if the attribute href contains “” or start with a “/”.

  103. Dante says:

    Sorry, but the above solution won’t work (except in Safari 1.0 and lower) as when you read out the href of a link, Javascript returns the full url of the link, not the literal content of the href attribute, even when you use getAttribute.
    <a href="">Dante</a>
    <a href="/">Dante</a>
    Will both return the exact same URL, assuming they’re in the same directory.

  104. Etienne D says:

    So where is the probleme ? If the script finds both of these issues he won’t open then in a new window whereas if he finds url starting with something else than he will open them in a new window.

  105. Vladamir says:

    I have noticed a number of people suggesting that new windows should never be used and that they were put into the www by the evil one him self. It’s a valid arguement, however, as the developer, its your resonsiblity to decide what is best for the site and the users not your own browsing habbits. If new windows are required, then you should use them, but, because the web has millions of users, all of which have varying abilities and preferences, it makes the dission over whether use new windows a bit more difficult. for starters, the only people who actually right click > Open In New Window are designers, programmers or people who surf 24/7, not the majority of internet users, not by a long way. The avarage user to website will blissfully click on all the links, follow them to where ever they go, use their back button, forward button etc, until they’ve finished then close down all the windows. I’m sorry if i’m going on a bit, i’ll get to the point in a minute. So, we need a solution that will work for everyone, yet be simple, and operate in the background, so the user can get on and do what they want to do. The very same arguement of new windows and user preferance could be applied to any part of a webpage, e.g. many desingers make sure that the type of their page is resizable so people with bigger screens can change the type size, but his is also very necessary for visually impared people, who simply can’t read small text. But how many designers ever think of using high contrast stylesheets, or styles specifically for colour blind users? You get annoyed at new window appearing, somewhere out there are thousands of user are who are highly pi@”?d off because they simple can’t read the text, and that makes all those late nights, short lunches and dangerous caffine consumption, completely pointless!
    My point
    Has anyone thought of asking the user when the link is clicked? for example, using the A method and <a>‘s with href="foobar.thml" and rel="newwindow", a javascript method could run on page load and add onClick events to them (just like BacMans) The onClick could then popup an alert dialogue that asks the user if they want a new window, or keep the one their using?
    In addition to this, instead of using an alert dialogue, you could write a simple method that dynamically renders an absolutly possitioned box on the screen, asking the user if they want a new window/tab/same window, and with bit of javascirpt cookie magic, a tick box that says remember my choice. That way, the users preference of opening windows isn’t forcefully broken, And every body’s happy.
    So the user has now decided how they want their special links to behave, they will need some way of easily seeing which links on a page do what. This is, of cause, handled by css. A special link could be rendered with a bit of right-padding, and a background icon that indicates whats going to happen when its clicked. Of cause the title="More Link Info" attribute should also be used.
    Our job as designers/developers/programmers should not be trying to find the easiest way for us to built and navigation the site, but whats easiest for the user, and know one knows the answer to that one. So i say, let the people the decide!
    p.s. i’m not a communist simpithiser, if thats what you are thinking. And yes, i can’t spell properly either

  106. Dante says:

    Et, sorry I misread your post. That solution would work.
    If you want a OK/Cancel box you use confirm, not alert. The “ask the user” solution sounds good. I don’t think a tic box would be good, as the next time the user clicks the link he might want it in a new window.
    Vladamir, Что является настолько плохим о коммунизме?
    I’m not very good at Russian.

  107. Vladamir says:

    Dante, I agree, a confirm (OK/Cancel) dialogue would be better as an alert box wouldn’t give any choice! Кровавые Коммунисты!!
    As far as the tick box goes, I admit it could be confusing, however, the point i was trying to put forward was the idea that websites are becoming more like applications. And, like applications, websites can have Options/Prefernces. I think it could work if a page was dedicated to these user prefences, and allow the user to switch things on or off, change the stylesheet, how much information appears on each page? It could be quite interesting to see just what would be possible? However, any preferences that are used should make browsing the site as easy as possible for the user.
    Нет ничего плохо о коммунизме, это имеет очень сильные идеалы. но, мировая история показала нам, что это может пойти очень неправильно. Не то, чтобы я думаю, что капитализм лучше! Я думаю, что мы должны все бросить наши компьютеры и телефоны в вулкан, и стать Монахами.
    И я – не русский, это – только прозвище

  108. Dante says:

    Ok, this isn’t a Russian Chat Room :)
    I had an idea for the new (coming soon):
    In the top frame (and please don’t yell at me for using frames) I could have a tick box: Open external links in new window
    Not as a popup, but maybe target=_blank
    For my new Yerba Buena Web Design and Consulting (coming…I don’t know) I use XHTML 1.0 Transitional. I could use strict since I don’t need target, but better safe than sorry.
    ???????, ?? ??????????? popups ?? ???? ??????????????? ??????, ???????? ???????????????? ?? ???.

  109. Etienne D says:

    Hi Dante,
    A tick box like this one ?

    <script type="text/javascript"><!--
    function targetLinks(boNew) {
    if (boNew)
    where = "_blank";
    where = "_self";
    for (var i=0; i<=(document.links.length-1); i++) {
    document.links[i].target = where;
    // -->
    <form action="">
    <p><input type="checkbox" name="targetbox" id="check"
        onclick="targetLinks(this.checked);" />
    <label for="check" style="cursor: hand;">
    Hyperlinks in new window
    window.onload = externalLinks;

  110. Dante says:

    Not quite like that, since the above code doesn’t seperate behaviour and structure.
    I haven’t really worked out the details yet. I spent most of today toying around with automatic syntax highlighting with Javascript.

  111. KAL says:

    Personaly I have set up my browser (Firefox) to open any link in the same window when left-clicking and in a new tab when middle-clicking. This is done regardless of whether target=”_blank”, or similar, is used or not.
    However, this does not work when the link uses JavaScript, as I am then forced to open in a new window (not even a new tab).
    Because of this, and because I see no reason for using strict without complying to the standard, I’ll have to go for C.
    Ideally I would leave it to the user, and thus use no method at all. But I guess it depends a bit about the intended audience, so I can understand why designers might choose to use it.
    Just please don’t force me to open a new window by using JavaScript.

  112. Dante says:

    After much thought my final answer is…C, Regis.
    Anyone who uses XHTML Strict will get what they deserve.

  113. Fazal Majid says:

    C. If XHTML 1.0 Strict does not support target, it is broken, and not worth bothering with. I tend to agree with Mark Pilgrim, XHTML Strict (and thus 2.0, hello, no img tags?) are a case study of standards groups (motto: “if we piss on it, it improves the taste”) indulging in intellectual onanism.

  114. Dante says:

    Needless to say, LOL.
    Fazal reminds me of myself 5 months ago (hellbent on anti-standards, now I love them). IMHO, W3C should start paying more attention to the needs of developers.
    Besides, if XHTML 2.0 becomes so horrid we still have good ol’ XHTML 1.0 Transitional, and if worst comes to worst, HTML 4.
    The point of this quiz is not whether you should open new windows or not, it’s assuming that we should and asking how we would. So pretend you had to open a new window – how would you do it? Now try and answer the question.

  115. Tim Hill says:

    Just a note about comment #1. I think the method was from an article at Sitepoint, by Kevin Yank.
    On the third page he makes a great point.
    “if the target attribute of the a tag is being phased out, does it really make a difference whether we’re setting it with JavaScript instead of HTML? Sure, the page will validate against the HTML 4.0 Strict and XHTML 1.0 Strict Document Type Definitions, but aren’t we technically cheating? … The answer is no. The Document Object Model (DOM), which governs the document objects and attributes that are available to JavaScript code, is a totally separate standard from (X)HTML. Also consider that the DOM 2.0 standard that was published in January 2003 (well after XHTML 1.0, let alone HTML 4.0) still includes this attribute. It seems clear that while this attribute is slated to be phased out of (X)HTML, it will be available to JavaScript through the DOM for the foreseeable future.”

  116. Chris Hunt says:

    I think opening in a new window is used way too often, but it’s occasionally necessary. When I do it, I generally go for C – it only happens rarely, and I tend to use Transitional anyway.
    If I had the time, I’d go for A, using an onload script that sniffs out particular classes and adds in a target attribute for the new window. Why use a class instead of a rel? Because I might want to add some visual styling to those special links that will open in a new window, and CSS can’t (currently) pick out rels. Why use a class instead of an id (like the ALA article)? Because when I markup a link as requiring a new window, I don’t want to have to edit a seperate js file to add that id to the list. I just want to add class=”help”, or whatever, to the a tag.
    In time, I could get rid of the onLoad script and use the target-new property in my stylesheet. I don’t have any dogmatic view on what should be CSS and what should be js, I just understand CSS better.
    Incidentally, KAL, I’m intrigued that Firefox allows you to suppress new windows unless JS is used to open them. Does this limitation only apply where JS onclick methods are used, or is it also true where you use JS to add target attributes via the DOM?

  117. Anonymous says:

    I’ll go with the browsers allow users to open links in new windows so why on earth are we forcing users to get another window on there desktop.

  118. Since I want to follow accessibility directives I certainly would use type A solutions.
    However, CPU usage should be kept to a minimal. Therefore I implement hyperlinks using the following method:
    in javascript:
    function setURLTarget(link, sTarget)
    { = sTarget;
    return true;
    next the hyperlink must look like this:
    <a href="” onclick=”setURLTarget(this,’_blank’);">the website</a>
    This implementation covers xhtml strict, accessibility rules and non-javascript browsers.

  119. Paul Odeon says:

    I would choose solution A. Any website that wants to popup a window is unlikely to be seen on a device that cannot support javascript. But without going into this further I am going to offer my solution which is based on Kevin Yank’s Solution but has been altered so that it does not rely on adding the target=”_blank” attribute which I know some people, myself included find questionable.
    The basic principle is to loop through all the anchors adding an onClick event handler to those with a rel=”external”
    Here is the function which does that:

    function externaliseLinks() {
    if (document.getElementsByTagName) {
    var anchors = document.getElementsByTagName("a");
    for (var i=0; i
    Then simply call
    externaliseLinks(); in your body onload

  120. chris jopson says:

    My immediate choice would be A, for the whole HTML=data, CSS=style, JAVASCRIPT=functionality idea.
    However, am I doing something wrong, or do methods like these inevitably lead to the “information bar” dropping down in IE with service pack2?

  121. I go with A, using a solution that does not require any hook in the markup:
    Elégantes Popup Windows (shameless plug)
    My 2 cents:
    - There was a comment made about using “_blank” and “new”. IMHO, another difference to take into consideration is that “_blank” is not blocked by popup blockers.
    - AFAIK, extending the DTD to use the target module creates an issue with the CSS validator (Jigsaw).

  122. Jakob says:

    I’ll go with the standard;
    not using target at all.
    There is really no need for it…