How evil is the target attribute?
As most of you probably know, the
target attribute isn’t allowed on links in strict HTML or strict XHTML. The thinking behind this, as I’ve understood the reasons behind this decision, and as I also see it, is that there are too many web browsers out there, be it in computers, PDAs or cell phones, and there are a number of factors that applies then. The most important ones seem to be:
- Many of them don’t support opening new windows.
- Most computer web browsers support tabbed browsing as well.
- It should be up to the end user, not the web site, to decide if a link should be opened in the same window, a new window or a new tab; web developers shouldn’t force such behavior on people.
While all this is good and respectful and sounds great in theory, it’s not that easy in the real world. Let me take a case in question: in one of the projects I work in, they had a demand that a link should be opened in a new window. I came up with the usual counter-arguments why we shouldn’t do that, but to no avail. However, the thing is, I partly agree with the customer and Project Manager in this specific situation; why a new window was actually somewhat motivational to use:
- The link was to a PDF file, with all the possible problems that might come of that, and as had already happened to many users (the web site in question is live), they clicked the link and then they just totally lost touch of orientation.
- Most people don’t understand the behavior of tabs or new windows, and a majority get confused when they get linked to another web site in the same window/tab. And yes, professional users, like I gather most of you are, have no problem, but we also have to regard our end users.
In the end, I went with using the
onclick event and used
window.open, and at the same time get perfectly valid code, but then it wouldn’t be as accessible and also dependant on scripts to function properly,
So, I feel a little perplexed about this: is
target really a justifiable approach in some cases (though it has been terribly misused), or is my example just the exception that justifies the rule? Should we take some responsibility in educating end users, or just deliver what they ask for?
New windows might definitely cause problems especially for inexperienced users. Also, the first argument (“It should be up to the end user”) is quite important. But there are exceptions, as Jakob Nielsen recently pointed out by recommending new windows for PDFs.
Assuming that this spec’s part gets stable some day, you will be able to use CSS 3’s
targetproperty to get rid of HTML/XHTML doctype constraints. But it will still be advisable to use new tabs/windows sparingly.
I’ve always thought that the third argument that it’s up to the end user wheter to open a link in a new window is totally wrong in many cases. You mensioned the pdf example, some others where i think a new tab/window is prefered is: Link collections, search results, most kind of listings (like threads in a bulletin board for example)..
I’ve argued this one to project managers and clients before myself and ended up loosing too. On those projects where my reasoning was ignored, I either simply held my nose and let my code be invalidated or opted for a transitional doctype which really left a bad taste in my mouth. I’d rather see an invalidation with one or two errors on a strict document than a green bar on a transitional one 😉
As for whether it’s really evil or not, I’d have to say that yes, the target attribute really is that bad. I don’t think that end-users are educated/experienced enough to really be execting anything at all. If they don’t know how to deal with a tab then a new window isn’t suddenly going to make sense. I think that it’s more likely that what doesn’t make sense to end-users is why their back-button is suddently broken. Studies (from what I read) consistantly show that users depend on the back button more than anything while surfing. target=”_blank” breaks the back button. For most users (the majority of whom are on windoze) the big red “X” in the upper-right means “close this program”, not “go back to that other site I was just visiting”. Especially with a Windoze UI where all windows tend to be automatically maximized, people just cannot be expected to understand what is happening.
I think that it’s 2006. It’s time to stop coddling managers and their “expected” behaviours. They don’t really know what users expect. We might take our geekiness for granted, but I say we’re still in better touch with what end-users should “expect” (if its anything at all) than a manager who doesn’t know anything about user interface design or useability. It’s time to start steering users towards more rational behaviours that are based on actual standards and forward-thinking and not half-assed marketing intuitions based on the 1997 browsing habits of some suit who thinks that he knows about the ‘net because his business card has a .com on it. 😀
PS Who me? Bitter? No, I quit that job 😉
targetattribute is fine if you’re using frames.
To put it another way: if you think
centerelements (or even
styleattributes) are OK, then feel free to use
IMHO, of course. 🙂
One of the drivers behind deprecating the target attribute is accessibility. Try managing a host of popup windows when you’re using a screen reader.
I think Allen has got a good point concerning the back button. Novice users are usually comfortable with the idea of moving between pages and then clicking back.
Users who are more familiar with multiple windows and tabs are also more likely to be aware of the “open in new window” functionality, and will use it as they wish.
If there is a need to open new windows, the user should be made aware of the fact that the link will open a new windowm (again, think of the screen readers). Alternatively, add two links: one to load the content into the current window, and one to open the content in a new window.
Why do you think that? Every time my mother is surfing, she is so confused when the “green little arrow” in the navigation bar suddenly doesn’t work any longer. And I would really consider her a typical internet user.
I agree with you in so far as I also think PDF files should not open in the same window; but instead of opening them in a new window, I would offer them for download directly. (I’m not a friend of PDF-in-browser view.)
I agree, if used, it should definitely be used sparingly.
Also, regarding CSS 3, not sure if I think CSS is the correct place to put such behavior…
Well, it’s a difficult question. I think it’s ok to say it’s up to the end user, given that they do understand to choose how to open it in different ways.
Ah, I love a bitter tone with a glimpse in the eye! 🙂
And I definitely agree with a strict doctype with some minor validation error compared to using a transitional one just to get it through the validator.
Very interesting argument about the back button!
Tommy, Robert W, Jules,
Yes, if the link will indeed force the user to a new window, it can be good to have that information together with the link. I’m not really sure two links would be a desirable approach…
I understand about the back butto, but many people I’ve met/seen surfing has reacted like:
when a link to an external web site has opened in the same window. I definitely get the dilemma, though.
PDFs should definitely be in a new window, if you ask me. Like Jakob Nielsen said, people don’t understand it otherwise.
No, it’s not about a bug or a setting, what I meant was people losing context if a PDF document opens up where the web site they were visiting just were.
Then, regarding bugs: in my experience, opening PDF documents in a web browser has been pretty shaky, although it has gotten better lately, especially when trying to do that in Firefox.
Definitely a reason, but not the only one, right?
The bug isn't with your web site, it's with the PDF reader plugin. If users get lost when a PDF opens in the browser then the plugin shouldn't do that; the plugin should be fixed. (You can change your preferences in mean time.)
If "external links" should open in new windows then that would be the default browser behaviour. It's reasonably easy to determinate whether a link points to an external resource or not.
The target attribute isn't included in Strict because it belongs to Frames.
Yeah, it is still a needed attribute/concept.
If you have a site, that uses a "shared" widget, as a popup (not ads, but a real, meaningful popup), you want the popup to display, in a named window. Likewise, if the user bury's the popup (accidental, or otherwise), rather than open a new one, it is handy to reference the old one.
I've seen some horrible apps, that open dozens of calendars and such. Where targeting by name, would avoid this.
Just face it you were an evildoer. 😉
"Ã¢â‚¬Â¦I understand about the back butto[n]Ã¢â‚¬Â¦"
You did say you like people catching typo errors didn't you?
The target attribute is the most evil attribute in (X)HTML, it must not be used under any circumstances, least of all for PDFs!. Jakob Nielsen’s recommendation to open a new window for PDFs is, suprisingly, wrong.
As the author, you do not know how the user’s system is configured to handle PDFs, any argument that says PDFs should open new windows are unconditionally depending upon the default (and, yes, often buggy) behaviour of Adobe PDF viewer and IE or Firefox.
The user may have configured their viewer not to open within the browser (there’s an option in Adobe’s preferences for this, but it seems to apply within IE only, or they may not even be using the Adobe viewer). Do you really want to give such users a new blank window, while their PDF views in another application?
The user may have the PDF Download extension in Firefox (or equivalent), or otherwise configured their browser to always save the file first. Again, do you want to give such users a new blank window?
Avoiding it in favour of a window.open() script is no better, and those who suggest that this is somehow “unobtrusive” fail to understand the meaning of the term. An unobtrusive script is not simply one that is external from the document markup, it is one that exhibits no obtusive behaviour, and forcing a new window is one of the most obtrusive behaviours around.
Those who argue that new windows should be opened for external sites fail to realise just how many different sites a user may visit in a day. If every single one of them employed this technique for external sites, imagine how many windows the user would have if they didn’t continually close them. That, in itself, is a job the user shouldn’t be forced to do.
The best approach to take is to inform the user what type of file you’re linking to. Let them make an informed decision about how to open it on their computer, which can meet their requirements – not yours! This applies to all file types, not just PDFs. DO NOT use the target attribute under any circumstances. It is evil! (except for within frames, but frames are evil too)
Lastly, sculder, regarding the validator saying invalid document with 0 errors, that sometimes happens when you have the DOCTYPE incorrect. It is case-sensitive, make sure you copy and paste it correctly from this list of DTDs.
The decision, I believe, is to extend the DTD. The truth is that for now, of course, DocType Definition files are ignored by browsers and even the validator returns "Invalid XHTML document, 0 errors" (very funny, don't you find?) if you try to change it and use the structures you added in xhtml files. So, there's no use in that. However future should change the situation, as we will get fully extensible xhtml, as promised in the conception of the language.
Apparently I was… 🙂
And thanks, I hate typos! 🙂
I'm not sure a custom DTD would be a good option either, I'm more wondering if it's ok under any circumstances to open a new window, than a way to get around that the HTML/XHTML is invalid.
Thanks for a very thorough reply, and if I'm not mistaken, your first visit here (at least your first comment). So welcome. 🙂
Very interesting opinions you share and definitely thoughtworthy. To explain the situation I was in, it was decided over my head. No extra text was allowed in the content, and it was a demand that it would open in a new window. So out with theory through the window, and just do as the people who pay say…
Therefore, I was really after what option would be the least evil ot the poor ones I had available.
How familiar this all sounds. I think that almost 3/4 of my clients brings forward the idea to open links in new windows. Fortunately I have been able to convince almost everyone to not do that.
I don’t know much about mobile browsing but my guess is that the many people who will browse mobile in a few years will not like all those windows.
Funny you say this, because I have seen the same behavior with many many (inexperienced) internet users. But they do it with EVERY window / application! Opening explorer. Closing with x. Opening outlook. Closing with x. Going back to explorer… hey were did it go? Looking for outlook. Hey were did that go? And repeating that again and again, even after I tell them “nooo! not the x!” .. but too late.. 🙂
Timely post for me, which has generated an excellent discussion and helped me out!
I've certainly 'lost' sites by clicking the close button, thinking the link had opened in a new window… especially with pdfs. And I've been frustrated by sites that open new windows way too often.
But I can also see the marketing departments point of view.
I also have the target dilemma on a current project. The directions page has a link to Google maps, which the client and I feel has a high potential for people to roam around to such a degree that the back button is no longer a viable means to retrace back to the original site… should you wish to! So I've used the target attribute to open the link in a new window (other reasoning being GMaps feels more like an app than a website, and people are used to closing apps when they're done with them).
But having read the comments here, the js solution sounds best to me, since the sorts of devices that don't support new windows are also unlikely to support js.
Robert, I'm surprised that was my first comment here. I've been reading you for a while now, but it's impossible for me to keep track of which sites I do and don't comment on anyway. 🙂
Wrong. While this may be true for many browsers, it's certainly not true for all browsers with all configurations.
I have my Firefox configured to never, under any circumstances, open a new window or tab unless I explicity request to do so myself. This includes window.open and the target attribue, both of which just cause the the page to load in the same window, like a regular link.
It does cause some problems with those that annoyingly use window.close due to a bug that allows scripts to close windows they didn't actually open, but this bug has (apparently) been fixed in the trunk, which will be in Firefox some time in the future.
I cannot stand sites that open new windows, and yes I have them redirected to a new tab. If I want that behavior:
I guess I just gave away my browser/platform combo. Of course all you'd have to do is check your logfile for my User-agent string anyway… 😉
LadynRed, Matthijs, Steve,
Thanks for thorough comments!
I mean, most of us do want to open every link in the same window for a number of reasons. Then, of course, to PDF links and links to such web sites as you mention, Steve, is in a gray area, depending on what behavior one expects from one's end users.
I didn't know you were! 🙂
I wish I would've had the opportunity to meet you one of the times I was traveling around Australia.
Also, thanks for contributing with the point that people have such settings in their web browsers. It just helps adding that argument to the others why links indeed should be opened in the same window.
Not really a shocker, many of my users have the same combination. 🙂
And, to make it even, I use the same combination. 🙂
Lachlan, your comment puzzles me a little?
I don't see how I'm wrong when your browser *does* support new windows *and* js? You have set your preference for browsing, which is great 🙂 Granted, window.close may be a problem, but nobody has suggested its use as acceptable.
My point is that many devices can surf the internet, but few besides regular pc browsers support js/flash/plugins etc. In most of those cases, using js to open a new window will not work, so it's less likely to cause a problem, keeping the linked content accessible, whilst allowing the website owner their preference for how the site is experienced by the majority.
Or something like that…?
I think the evil appears when the browser (or browser configuration) allows the PDF file to be embedded in the browser with a whole new set of controls. This, as Mr. Neilsen points out, is confusing. We've all done it: clicked on a PDF link, viewed the document embedded in the browser then unintentionally closed the browser subconsciously thinking we were in that application, not in a web browser.
The PDF link should open a new application window rather than embed itself into the current browser window or new browser window.
On the other hand, if embedding is done right, then the web surfing experience can be maintained. What bothers me is when the plug-in adds a bunch of new controls, many of which duplicate the functionality of the browser. (Why does the Acrobat plug-in have a print button? Okay I want to print. Do I click that print icon or that print icon? Which one is used when I choose File:Print?)
If the plug-in would simply show the document and provide a browser-like experience, the surfing paradigm would be maintained. Most plug-ins, however, want to impose their application's UI paradigm on the surfer. This is where plug-ins become evil in my opinion. Okay I'll stop ranting now. I really hope this relates somehow to the target attribute. Sorry, Robert if it doesn't.
Maybe it's just an example, but the value for the <code>href</code> attribute should always be a valid URL. Your <code>rel</code> example sounds valid to me.
No problem, I think your opinion is very valid here. The duplication of icons when viewing PDF in a web browser window is definitely confusing. Personally, I prefer when PDF links automatically opens up in "normal" Acrobat, like SilentWarrior suggests.
Well, sure. E-mail me or give me a call next time you're in Sydney.
Because a browser that supports JS and has popups disabled is not much different from one that supports some JS but doesn't support popups at all.
Well, it's not like I'm there very often. 🙂
I've been there twice and I hope I get the opportunity to visit your country in the future again.
From my limited XHTML experience (only been using it for a year now), I’ve found writing a custom DOCTYPE to be a very workable solution for the target attribute. Irrelevant of the good or evil behind it, I’m personally used to the de facto internet standard of ‘off-site links open in new windows,’ especially when 95% of the site’s links are intra-site. The user gets used to ‘going from here to there in the application,’ and when you suddenly kick them to the other side of the internet (especially if they wander to a page that breaks the back button), they can have trouble coming back. And if it’s a really minor offsite link (e.g. ‘where to get Mozilla Firefox’) it’s all the more stupid.
Anyway, my point is that I saw a number of people talking about how the modern browsers don’t even download doctypes, and from what I can tell, this is totally incorrect. (At least if we’re talking a modern FireFox, Mozilla, or IE6.) For a specific example, check out Extending XHTML: Target and Strict, which is actually where I first learned to customize my DocType. There is absolutely no good reason to write invalid XHTML in any case; the whole point of these standards was to make browsers render consistently, and quirks mode is the surest way to end up in a flashback from the IE/NS Browser Wars. (Watching IE’s box model explode when I muck up my XHTML is always a nasty surprise.)
Thank you very much for sharing your experiences!
Sure enough, I just put my foot in my mouth.
I was playing around with custom DOCTYPEs after posting, and it turns out that if you serve up XHTML with a custom DOCTYPE to Mozilla/FireFox… along with a Content-Type of application/xhtml+xml, things can go sour. (Or application/xml, or text/xml for that matter.) http://developer.mozilla.org/en/docs/XML_in&#… is very enlightening in this regard. Apparently, when it's in strict XML compliance mode (when it gets one of those three MIME types I mentioned above), Mozilla – and therefore Firefox – pretty much never downloads external entities (e.g. DTDs). And worse yet, it completely ignores character entities unless you're using one of nine XHTML (or SVG) PUBLIC identifiers in the DOCTYPE declaration. I actually ran across this because Firefox barfed on entities in my document when I tried to switch it to xhtml+xml.
Now, you can use an internal DOCTYPE, like:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/tr/xhtml11/
DTD/xhtml11.dtd" [ <!ATTLIST a target CDATA #IMPLIED> ]>
…which works perfectly in Mozilla/Firefox… but leaves chunks in Internet Explorer, a trailing ]> at the beginning of your page. Which tragically kicks IE back into quirks mode. (Of course, if you're conditionally sending text/html to IE and application/xhtml+xml to Mozilla, you could also conditionally send one DOCTYPE or the other and be happy.)
I guess what I'm getting at… is that you can use a custom doctype, but no browser actually bothers to download external DTDs… and nobody really seems to care at all except the W3C validator. Both IE and Mozilla work still run in Standards mode when the MIME type is text/html if you put in XHTML Transitional 1.0, XHTML Strict 1.0, XHTML 1.1, whatever (you can check document.compatMode, honest).
So…. what everyone said above was basically right, oops. Gonna back down and say… maybe there is a time when you go ahead and write invalid XHTML because, well, none of the browsers even care about your DTD. As for me, I'm serving up that internal DOCTYPE above in application/xhtml+xml to Mozilla/FireFox and the W3C validator (check here if you're interested in specifics), I send my custom DOCTYPE in text/html to IE. Sure, IE doesn't check the external DTD, but it helps me sleep easier at night.
And I can open new windows alllll day long! [wugga wugga wugga] Take that! 🙂
Oops, looks like Textile or whatever munged my link, wrapped underscores in italics. That was http://developer.mozilla.org/en/docs/XML%5Bundersco….
I'll… stop posting now. 😉
Ha ha, no problem! 🙂
Thanks for the information!
It's because Mozilla and most other browsers than can deal with: "<code>application/xhtml+XML</code>" use only a Well-formedness Checking XML Parser and not a Validating XML Parser.
I use custom DTD on 12 pages knowing fully well, they won't use the DTD I wrote. They have the option to do so, actually I used it to create EMBED several years back.
Good to hear that you're on top of things! 🙂
Sorry, I'm a little late to the party.
With regards to this, I would argue that HTML/XHTML markup is not the right place to put it either. In ye olde "Holy Triumvirate" of web standards, the DOM is the right place to put behaviour.
This simple summary leads me to believe that taking the attribute OUT of XHTML was a well-considered move on the part of the W3C.
the smallest virus in the world ever, created some time ago…
Better late than never, right? 🙂
It's a valid point but the the built-in popub blockers that most web browsers have on by default nowadays, the problem isn't as big as before.
I think the W3C went a little too far with deprecating the target attribute. Sure, the user should decide whether he wants a new tab/window but I think there are some cases where you want the user to stay on your site and only open a second one.
I understand the reason and thought in regards to the W3C's standpoint on this issue. However, I actually disagree with it completely. There are many different situations that call for a new page to be opened and the choice should be up to the developer and the client not the W3C. If a designer has taken the time to learn web standards, then not only does he have an understanding of web standards, but he is also capable of making a sound decision based on the task at hand.
For an example, I recently designed a website for a school project that promotes a musician/band. There are two links that must open a new window. One is a flash music player and the second page is a lyrics page. For the lyrics page, the navigation is identical in appearance to the main site with the exception that the links are now the song titles and only navigate the user to the various songs listed on that page. It's clear to see why it would be important to have these links open in new windows.
To quote a definition provided by Google of what is web standards –
"Formulated by the W3 organization, these standards enable people to create websites that will work in almost any browser or internet-enabled device"
Ultimately, I think the choice is up to us and the project at hand. If we use the target attribute, the rest of the code is still W3C compliant. The only loss would be that you dont get to put the groovy tag on your site that proves it (since you would fail validation). The best judgement call on a situation like this would be to review and research the advantages and disadvanteges of both. Then you are able to make a sound and practical call based on the project.
Yes, and that's the interesting part of this: how far should W3C's reach go and is it ok to stray from the rules sometimes?
Thans for a long and interesting comment!
I agree, but my take is that most web developers don't take the time to learn to do their job properly. Therefore, a strict validation is a way for W3C to force them to adhere to validation rules, because they can, in a simple and tough way, see if their web site is correct or not.
[…] o estÃƒÂ¡ permitido el uso del atributo target. He estado leyendo un par de artÃƒÂculos , [ […]
[…] pening new windows might make sense). Robert Nyman presents an interesting summary in this blog post from February ‘06. In Nyman’s […]
What's wrong with…
My Web Site
This is a very interesting thread especially since this limitation is new to me (I have been using transitional up until now). I should point out that I am very much a pragmatist in this subject rather than a purist.
The thing that strikes me about the comments above (particularly Lachlan Hunt's) is that frequently the ineptitude of the average user is used as an argument _not_ to use this attribute: don't confuse the user with a new window! But that clearly works both ways – a new site suddenly replacing everything else is also confusing.
Surely it's in the web designer's interest to use new windows when appropriate – where it fits with the flow of the site and in particular where content forks. My line of thought is that this would lead to less confusion than the alternative, which is a disassociation from the original site's content (take for example an external link from the middle of a news article – or a help page linked to from a long half-filled-in form). In these instances, a new window does not destroy your "saved state" if you will.
All that said, the topic is still a new one to me and there's plenty of space to change my mind as the variety of devices proliferate and I come to terms with different modes of navigation. My browsing habits currently use new windows heavily and it's always seemed pretty efficient to me 🙂
Thanks for your input!
I can say that my web browsing habits consists of new tabs all the time (using Firefox). And there's nothing wrong with that, but I think there's a vast difference if you as a user choose to open a link in a new window/tab by holding down a certain key and clicking (or similiar behavior), as opposed to a web site forcing a new window upon you when you actually wanted to open it in a tab or maybe to replace the current content in the same window where the link you initially clicked was.
[…] al stuff, Web design Robert Nyman gives a good answer on why you should use the How evil is the TARGET attribute in A tags. […]
[…] al stuff, Web design Robert Nyman gives a good answer on why you should use the How evil is the TARGET attribute in A tags. […]
I think there is a serious problem to come for webdesigners if we can no longer manage our windows. It is obvious that any site a bit complex needs several windows to guide the visitor (main nav page, index page, forms, etc) and of several kinds (normal windows, full screen windows with ou without scroll bars)… and it is also evident that only porn sites or crook sites abuse of these very useful features (and the obvious solution is not to go on those sites).
There was already serious problems with classical solutions such as target and window.open (opening a full screen window, changing from a full screen to a normal window…) but if we let do, we shall soon have only one small window surrounded by numerous menu bars, whatever it contains a little advice, the main content, or a large poetical image which deserves a full screen.
And nobody to complain!! to post a message to the W3C is a complicated process, and we must pay…
There is also a hiden lobbying: on every french forum dealing with the full screen problems, we find the same short message telling that full screen is very bad and the guy does ctrl+F4 each times he finds one…
Thanks to Robert Nyman to keep this page, it is difficult to find places to speak of this issue.
Two hours to change a page from TABLE and FONT tags to CSS… multiplied by the number of pages on the internet, that makes as much lifetime loss as Hiroshima. And even worse, as the peple killed at Hiroshima at least are no longer unhappy, when rewriting a page to ancient HTML to CSS is rather a tedious task… at the expense of enjoying life, family life and so on. Did they think to this when they decided to suppress these tags?
OK, HTML needs to evolve, the semantic web is a great thing, but at least, ancient pages should be still declared into their ancient language and still be understood by the browsers, even if we forbid to create new pages with these ancient languages. In place of being threatened to disappear and their authors treated as bad code writers…
The issue with TARGET and full screen is also a threat to the freedom of expression on the net: We should not present a nice image otherwise than surrounded by menu bars, tool bars and other grey computer gear??? Do they understand that suppressing the full screen is equivalent to CENSORING poetry on the net? The W3C, and Microsoft, and Firefox also, should accept that Internet is not only for computer geeks spending their time to solve useless problems att the expense of real life in the world. It is mainly used to convey ideas and expression. And the vast majority of Internet users look for these ideas, infos and expression, not to find solutions to problems that bad software writers created themselves.
The problem with full screen started with Firefox. But Internet Explorer and the W3C soon joined to the anti-window censoring. Why do they do this? Who control them? Who do the anti-fullscreen and anti-windows lobbying on every forum, including on this page? That this lobbying presents itself under different names each time strongly suggests that something dishonest is going on.
I filled a bug to bugzilla-firefox, as F11 no monger works. Still no reply… I tried to reach the bug submission system at microsoft, for the same reason… will you be surprised, there is a bug on their site, and I found myself on a form to create a microsoft passport without even telling me what it is. And on the W3C site, we must pay, and spend hours to find the right place to post a complain (if any such place exists).
What I say here will probably not be heed by the concerned people, but at least it will be written once in one place on the net: if non-democratic measures destroy our work on our sites, and we can even not complain for this (to obtain more sane measures), this is equivalent to a deliberated attack, and I will use other methods (oh, not violent, not illegal, without noise or scandal, but dishonest people would be well advised to stop fooling about).
Robert, I don't think that sites "force" users to open in a new window. In a well designed site, the webdesigner tries to guess what is best for the user, eventually guiding him.
For instance in my site shedrupling.org, I have a main navigation window, where you can go from one page to another without any restriction (all the links are on top of the pages). But I also have forms to post messages to a forum. And all the links to these forms open in a new window, because the user will probably want to compare his writing in the form to my text in the main page. This is impossible to do if there is only one window, we would lose the already filled form. More, I use TARGET="_blank" to link to these forms, so that if the user starts a new form he does not lose what he was writing in the first form. (Users seldom open many forms, unless they want to test the limits of their system)
I have another project for this site, having a music background following the user from a page to another. But this needs… a popup window.
There are certainly real issues about full screen, target and all, but the W3C and browser developpers should rather fix these issues, for instance not letting a site install a software on our computer without us even noticing it!!!! And if users prefer to open all in one window, or into tabs, they should be able to configure their browser that way, knowing that they will lose some basic functions.
Brett, Richard, Likchenpa,
Thank you for your comments.
I don’t think you should be manually coding in the Target attribute unless it’s under a Transitional Doctype.
That said, if you’ve scripted it, that’s probably not a bad thing.
Personally, I'm not a big fan of adding invalid attributes to the DOM, although I guess it is in some sense better than invalid HTML, to begin with. Good article, by the way; thanks for the link.
There is no reliable workaround, it is not a coding issue to which there would be a coding solution, we can just do some "transitionnal" hack.
This problem is really a non-reductible disagreement between the W3C proposal and the interest of web developpers and users.
I would add a thing besides the subject.
5-7 years ago, it was easy to do a site, it was some tags Ã‚Â«htmlÃ‚Â» Ã‚Â«bodyÃ‚Â» Ã‚Â«fontÃ‚Â» Ã‚Â«tableÃ‚Â», edit wysiwyg with free Front Page Express and see it exactly the same way with Internet Explorer. Anybody could create a good looking site, even impaired people with low IQ or third world people just knowing to read.
Browser manufacturers and W3C should seriously consider that browser war, bad browsers (which don't implement standards properly), improper standards (like dropping "target") and uselessly complex standards, all these are a real brake for the freedom of expression on the net. Not for THEIR freedom of expression of course, but for the freedom of expression of a vast majority of people in the world.
I would say that the WYSIWYG tools wasn't any solution back then nor is it now. It worked in Internet Explorer, but in no other web browser.
For me, working as a web professional, browser sniffing doesn't need to be done for PHP and the likes. The only sniffing necessary is done, through conditional comments in the HTML code, to serve IE and its insufficient CSS support (and yes, that goes for IE 7 as well).
A long time ago, Front Page Express was THE only editor, Internet explorer was THE browser, and Ã‚Â«htmlÃ‚Â»Ã‚Â«bodyÃ‚Â»Ã‚Â«tableÃ‚Â»Ã‚Â«fontÃ‚Â» was THE correct way to code a page. Of course this changed with the appearance of Netscape, but in the begining it was rather a political step against the monopoly of Microsoft, rather than improving the standards. Improving the standards came later with the CSS and the like.
An example of CSS difficulty which can be solved only with browser sniffing:
A transparent clickable zone in front of an image (a common and perfectly legitimate method).
With IE you need the style:
background-color: gray ;filter: alpha(opacity=0);
With Firefox you need:
With Opera you need:
background-color: gray;opacity: 0;
With Safari you need:
(not tested, I don't have a Mac)
If you know which of these CSS is the correct recommended method for doing this, please tell me, I will change all my PHP browser sniffing routines to switches, and place the standard method as the default: case. The browser which never appears in any switch is the winner. (Useless to say IIE6 has little chances to win).
Another example: try to center vertically a text in a block.
Another example: try to share a block in two columns of equal width.
Another example: try to hide a text (anti-spoiling) with an opaque div which becomes transparent when you hover the mouse on it.
What I think is that CSS is a great thing, yeah, but I already have done only three pages, and I already stumbled on more that three unworkable issues like these. Not to speak of the topic of this thread, suppressing the Ã‚Â«targetÃ‚Â» attribute, because, they say, some simplified browsers don't support multiple windows (Yeah, if bykes carry only one passenger, so cars must too carry only one). Or the other "very good reason": beginners don't understand the behaviour of multiple windows (This is as if we simplified orthography, because beginners can read only simple words).
What I think is that they should allow most people continue working in the ancient way (Ã‚Â«htmlÃ‚Â»Ã‚Â«bodyÃ‚Â»Ã‚Â«tableÃ‚Â»Ã‚Â«fontÃ‚Â») which is easy to use and far enough in many cases (The pages I translated in CSS don't appear better than in former html, except for % screen size adaptation). And, for CSS, it is OK, but they should put people able of normal common sense to work on it, to implement the obvious solutions to the problems I quote above (and many others, if I extrapolate).
You know, if there are common and legitimate thing we can no longer do with a new standard, it is simply that this new standard contains mistakes. This is something human, something which happens, there is no shame to do mistakes, it is not an heresy to show mistakes, and the obvious and only solution to this is to correct the mistakes, not to invent who knows what ad-hoc theory as that it would be bad to do the things we can no longer do because of those mistakes.
Thank you again for maintaining this page. I am seriously considering creating another one myself on this topic, because I am really fed up to spend days to work issues which needed only an attribute in ancient HTML.
I have been developing web pages since 1998 and FrontPage has never been the editor for me (except for the obvious validation round). I have always used HomeSite to have clean code that I can control myself.
Opacity is beyond what most people want to do with CSS, in my opinion, but just to answer your question. With opacity it is the same case as with most other things: there's a standard way and a Microsoft way. You use <code>opacity</code> for any web browser but IE, and for IE you need to use their filters.
Vertically aligning text is about having a block element within a block element, alternatively using the <code>display: table-cell</code> CSS property (again, not supported in IE).
And so on…
There are ways to achieve many things in CSS, and the advantages vs. table-based layouts are many. Less downloading time, less and more manageable code, better performance since the CSS is cached, separation of content and presentation, being able to instead have semantic HTML for search engine and accessibility reasons and so on.
Yes, I understand that professionals never used FrontPage, for obvious reasons. But millions of people did, as casual web designers. Anybody who wants to create a site to express an opinion or present something, will do it once, and thus will not buy professional tools or learn complex things, and will not bother about having the best code.
About my example on opacity, I am not seeking to use opacity, but to create a transparent clickable zone. You get the difference? Opacity is only the mean. You could call it hshdjkdkfkf as well. Alas this mean is different for all those three browsers, not just with IE. All those tricks are well known by a professional like you, but they are a real problem for anybody who just wants to create a site once. In this way this complexity is hampering the freedom of expression of all those people, the vast majority of sites.
And I don't oppose CSS, I agree with all your arguments, I just regret it contains so much avoidable tricks and traps.
Thank you for your tips, I shall try them. And if I can vertical align my text with a given browser and not with another, so bad for the later. At a pinch, if there is a function which completely don't work, I will place a message suggesting to use another browser. I already did this with IE, untill I found a workaround. But they will probably get another punishment of this kind, as they suppressed the full screen, completely messing a hundred of my pages of art work on "the marvelous world of the Eolis". Firefox could be the next on the list, if they continue to reduce access to the the full screen mode.
Excuse me to post again without waiting for a reply, but I think the problem in this domain, as in many other domains, is that everybody grasps at his opinion, seeing only the advantages of the system he supports, and getting blind to all the defects and inconveniences of this system. This is hust polemics, rethoric, not a fair exchange or discution. (Please don't take this as personnal!!)
It is however well known, in this 21th century, that we progress only when we eliminate our defects. Thi is true for great moral concerns, but also in down to earth issues like computer science. But this requires the will and ability to face our mistakes, and the humility and courage (yes it is the ultimate courage) to see our mistakes and correct them.
In the beginning I was a strong supporter of free softs, for political/philosophical reasons even far before computer reasons. But my experience with this turned to the nightmare… I would sincerely regret if the only result of the whole linux/firefox experience would be to push ahead Microsoft in the way of improving its products (a thing it could easily do, with ten of thousands of developpers, if one day some rational person takes the commands).
Same for Firefox: I posted two bugs in bugzilla, on the full screen problem (a painful issue for me and for all artists). The first time, I was abruptly rebuffed, the second time just ignored… this is very far of what is called "a friendly community of developpers"…
Same with CSS. The CSS spec is not a divine commandment, which would forbid us to do certain things (such as using multiple windows with the Ã‚Â«targetÃ‚Â» attribute, or other ununderstandable taboos of this kind). The CSS spec is a human building, with human authors and maintainers, which would easily be bettered with some simple fixes. The problem is that passing a message to the authors of the spec seems as difficult as speaking to the author of the ten commandments 3000 years ago on the SinaÃƒÂ¯ mountain…
Ha ha! 🙂
happy you did not take it as personnal.
But I hope concerned people will move…
Me again, hahahaha…
This page http://www.shedrupling.org/art/lotr/revelfic2.php
features a nice illustration (in the bottom) with a link "click to see in full screen".
It was THE standard way of coding, it worked with IE, and with Firefox as well. But Firefox made the full screen more difficult… and recently IE frankly suppressed it!
I though the case of Opera would be the simplest, but they have a useless "fit to width" option which… unfits my screen adaptation, so that I have to warn the user so that he may disable this…
Is all this mess really a progress?? Is really Internet better because of so many useless hassle? If we keep with a Tolkien comparizon, I shall call it the crooked way toward Valinor…
Please corrrect the URL above: http://www.shedrupling.org/art/lotr/revelfic.php
(revelfic2 was a draft)
[…] as of today, full Podophile feeds for all. target=”_blank”. I stumbled across […]
[…] aScript open browser window pool. Now before anyone shouts at me, or calls me evil for using the target attribute, you do have admit its pract […]
Hmmmm…. Why the target "_blank" alone would be a problem? It is very useful into a link page, to send the user toward the various sites without losing the link page, or to send the user toward an accessory page without losing the main. It is very frustrating when we browse a link page and we lose the main page. So when I design a link page I do what the user needs. Personally I often need "_blank", but never had the occasion to use the three others.
I am afraid that many "reforms" of the Internet don't arise from a real knowledge of user needs and page display needs, but, for whatever reason, of a very restricted view of only a special case.
Yes some attributes like "_blank" or opening pop up or full screen can be misused. But we can misuse cars too, to run into somebody and attempt to kill him, and even with a simple table knife. Must cars or knives be forbidden for this reason? Wake up, the world is much larger than any of our personal scopes…
You may have heard that if you have good content, people will come back no matter what. That's only true if they remember the name of your web site. You could have the best content in the world, but if someone surfs in from a search engine, loves your web site, then leaves a few minutes later by following an external link, they will probably lose track of your site unless you open the external link in a new window. Haven't you ever become slightly angry because you didn't get a chance to bookmark a cool site that you stumbled upon? That has happened to me many times and I'm sure it has happened to other people too. I used to hate offsite links that opened in a new window, but now I appreciate them. The new window allows me to explore freely without fear of losing the original web site.
Sometimes you don't want to use the back button if you fill out any kind of form at another web site, so the original site may be lost although you really wanted to go back there. It's much easier to simply close a window so you can get back to the original site. So people who complain that opening a new window "breaks the back button" of the browser need to understand that many times, the back button becomes useless anyway.
[…] an fÃƒÂ¥r dÃƒÂ¥ ett valideringsfel i sin kod. Robert Nyman tar upp detta alternativ i artikeln […]
Killing target attribute was the most stupid idea and I am glad that modularization brought it back.
You need new window for:
– Flash site (back button doesn't work anyway)
– Media players (they crash and burn and you lose back button functionality again)
– PDF documents (they have their own back button)
– Showing large images (you can continue reading while they load, especially on slower connections or if you are downloading other things in the background)
– Forums (managing attachments for the posts for example)
There are many other circumstances when you might need a new window, one of them being on the site where you get "warning: page has expired" when you click on the back button (reason: security of transaction), and you can't go back to the site you were before and thus you lose the link and have to retrace your steps to get there which is sometimes impossible (for example because of updated Google pagerank in the meantime).
Given all this, removing target was a bad idea. Allowing it through the module is a step forward after taking two steps back. Integrating it into XHTML 2.0 would be a much better thing to do.
Sorry for the second post, but I forgot this:
– You need new window for sites where you need to make it clear that you are not responsible for the content which opens in a new window.
– New window is preferred for offsite links.
What would be *really* useful would be an attribute "open in new tab". You are correct that one of the problems with the target="_blank" attribute is that most people nowerdays used browsers which support tabs.
yes, opening in a new tab. But it is t up to the user if he wants to open new pages in a tab or in another window. There are arguments in both way, especially that if we use windows we have the tabs in the system tray. So the attribute "_blank" is enough for this.
The problem come when the site needs a special window, full screen, or "half" full screen (no menus, but still the cross and the system tray) or small pop-up windows for explaining something while hovering it above the main window. This worked well for windowed only browsers, but tabbed browsers just ruin this model. Especially the site designer don't know how the page will be displayed (window or tab). So that,in fact, I alway disable tabbed browsing and am happy to use the tabs in the system tray.
There would be much less problems in lefting what is working in Internet, in place of enforcing web designers to modify their sites all the time. I have pages which are 7 years old, and which are already up to 2-3 rewriting. This is plain ridiculous.
It seems as if people have a lot to say on this topic. However it seems that many have forgotten that the majority rules. The most important factor here is the majority of end users (your end-users). Simply look at the numbers and you will have your answers. Without regard for your coding "ethics", why not do what any wise programmer should do and look at the usage of such programming. How many people "X" and how many people "Y", etc. If you want to be a snob, be a snob, but if you want to do your job better, follow the masses (specific to your application, of course). Why zig if they zag? Why try to teach them a lesson if you precluse yourself from ever even having the lesson addressed and absorbed? If you program for programmers, fine, do so with snobbery. If you program for John and Mary Lunchbucket, lose the snob and do what the numbers will clearly dictate. If you cannot read the numbers, you should not use a computer anyway. How is your computer, browser, etcetera set up differently from the Windoze user that just walked out of Best Buy with a new computer because his old one crashed and burned full of virus and had never been updated. Unless you are targeting a smaller crowd of geeks, do not try to push the thumbtack in wide-end first (because it hurts less if the sharp part faces forward). If you think that the average user has made significant changes to their browser settings, get off the sleeping pills and open your eyes.
Well, Mark, good post, you gave no info at all, we even not understand who you are flaming 😀 !! Just one mistake: it is not the majority who rules when designing a standard, but technical rationality. and it is discussed with technical arguments, sometimes technical trade off, but certainly not by an insult contest.
target attribute for hyperlinks is rehabilited in the draft of HTML 5, see this link:
the argument used is that Target is useful with iframe.
[…] Domain. Hmph. The way you’ve displayed your subpage link is really ugly (and this isn’t me being deliberately caustic). It would be much prettier (and logical as well!) if you were to have a simple sentence at the end of this page after all the other paragraphs, along the lines of “For a list of sites I recommend, please click here for the links page”. (By the way, on the links page, it’s “blogroll”, not “blogrolls”, and you should also refrain from opening new windows.) […]
I'm arriving late. Good conversation here.
I prefer not to use the "target" attribute for all the reasons exposed above.
When i have to link PDF files, I put a sentence telling the user that the link points to a file of x size, and he/she has to right-click and choose "save" in the contextual menu.
In new browsers there are only 2 options when you right-click:
1) Open Link in new Tab
2) Open Link in new Window
I suggest this option (I think this will be implemented in all future browsers anyway):
3) Open Link in the same Window
This would solve the problem, because:
a) web designers could make any default action (on left-click), which they think best fit the user
b) users could always open link in their preferred way, ignoring the default action (and I think they should be able to see the default action, ex, when onmouseover event is triggered on that URL)
I'm surprised that neither browsers (AFAIK), nor W3C is included such useful option (I mean target="_blank" shouldn't be excluded from STRICT validation).
[…] How Evil Is The Target Attribute?—Robert’s Talk This entry was posted in Usability and tagged back button, links, mobile browsers, tabs, usability, users, windows. Bookmark the permalink. ← Zootool — The best and most beautiful tool for storing inspiration […]
I agree. No need to use target, particularly. Just let the user know what's coming next.
[…] How Evil is the Target Attribute? – Robert Nyman […]
[…] you want to know all the reasons, Robert Nyman touches just about all the reasons between his post “How evil is the target attribute?” and the comments that follow. But for the reason of simply staying out of people’s way […]
sadly, right clicking on submit buttons on forms, in Firefox 3.6 (or any other major browser), gives no option to open in new window, new tab, nor current window.
So all the talk about letting the user choose is irrelevant for form results… user can’t do it.
– All modern browsers open it in a new window or Tab,
– Leaves the dicission up tot the client,
– Aliviates those clients insistant on a new window and want your HTML to validate…..
[…] How evil is the target attribute? – Robert’s talkFeb 13, 2006 … As most of you probably know, the target attribute isn’t allowed on links in strict HTML or strict XHTML. The thinking behind this, as I’ve … […]
WARNING: Counter-dogmatic opinion ahead!
“It should be up to the end user, not the web site, to decide if a link should be opened in the same window, a new window or a new tab; web developers shouldn’t force such behavior on people.”
The people who push this are all people who know how to open links in a new window. Being aware of this convienience, naturally, they prefer to make that decision themselves. They might as well say “It should be up to ME, not the web site…”
If they were so worried about every end user they’d take hold of the fact that the reality is for many beginning users opening links to new environments in new windows is a convinience… one that an be abused but certainly not abusive in nature.
The flaw here is that it should be seen to be on the end users innability to override website defaults behaviors, or lacking the mechanisms to do so.