[Web Development]要不要打开新窗口 与 TARGET属性

转载自: http://diveintoaccessibility.org/day_16_not_opening_new_windows.html Day 16: Not opening new windows The one thing every web user understands is the "Back" button. It's an integral part of browsing the web. Follow a link, go back. Explore a search engine result, go back. Even my father can do this, and he's still excited when he can double-click the "Internet" icon successfully on the first try. In all dominant browsers, using the tag to force a link to open in a new window breaks the Back button. The new window does not retain the browser history of the previous window, so the "Back" button is disabled. This is incredibly confusing, even for me, and I've been using the web for 10 years. In 2002, it's amazing that people still do this. Don't do this. Don't force links to open in new windows. Please note that this tip is about you as a web designer, not you as a web user. If you want to open new windows while you browse, go right ahead. In Internet Explorer for Windows, hold down the Shift key while you click a link to open the link in a new window. In Netscape 6 and Mozilla, hold down Control. In Internet Explorer for Mac, hold down Command. (Some browsers such as Opera support advanced combinations like Control + Shift + click to open a link in a new window in the background.) The point is that the choice of whether a link will open in a new window should be the end user's choice, not the web designer's choice. Who benefits? Jackie benefits. Although JAWS does announce "New browser window" when a link opens a new window, this is easy to miss, as it is spoken wedged between the reading of the link text and reading of the new page. Home Page Reader has a better solution; it plays a distinctive sound every time a new window opens. And Window Eyes, another popular screen reader, gives no indication of new windows at all. And regardless, the "Back" button is still broken. If Jackie misses the "new browser window" announcement, she can not simply glance at her taskbar and see that two browser windows are open. She will need to read through her entire list of open windows, either using the JAWS-specific shortcut INSERT+F10 to get a window list, or the standard ALT+TAB. Lillian benefits. Her Internet Explorer window is always maximized (so she can see it), and new windows also open maximized by default. Furthermore, Windows XP groups multiple windows of the same application in the taskbar, so there is virtually no visible indication that a new window has even been opened. Suddenly, the "Back" button is disabled for no apparent reason, and Lillian has no idea why. If you were expecting her to read the rest of your web site after following that link, you can forget it. Bill benefits. His sister has set Mozilla to use tabbed browsing, so that Bill can look at the tabs and quickly remind himself which windows he has open, and also so he can quickly switch between them (using CTRL+PAGEUP and CTRL+PAGEDOWN on his handy dandy keyboard extension). Links that are forced to open in a new window will open an entirely new Mozilla window. Not only will this bypass his tabbed browsing preferences, but it will make it appear that all his open windows have disappeared, since the new browser window will not show the tabs that were open in the previous window. How to do it Don't use to force links to open in a new window. If you absolutely must open a link in a new window, explicitly warn the reader. This is a non-optimal, compromise solution, usually brought about by business requirements of "not being associated" with external content. For example, CNN's "related sites" page does this. If you have a "Links open new windows" checkbox, make sure it is off by default. Further reading Jakob Nielsen: The Top Ten New Mistakes of Web Design. "#1: Breaking or Slowing Down the Back Button. #2: Opening New Browser Windows." W3C Web Accessibility Initiative: Example for Checkpoint 10.1 gives an example of how to warn users if you have a single link that you absolutely must open in a new window. W3C Validator mailing list: Re: opening a link in a new window. For those who care about this sort of thing, you should know that the target attribute of the tag is deprecated, and will prevent your pages from validating in HTML 4.01 Strict, XHTML 1.0 Strict, or any future version. WebAIM mailing list: mailto: links open new windows. The consensus is that mailto: links are not an accessibility problem, even though they generally open your email client in a new window, because this behavior is completed determined on the client side. A web-based mail form (like Radio uses) may be a better overall solution, provided the form is accessible. A web-based form will work for visitors without integrated email clients (by misconfiguration or by circumstance, such as being in a public lab), and it protects your email address from spam harvesters without resorting to inaccessible Javascript tricks. On the other hand, some people really like their email clients due to familiarity, functionality (such as built-in spell checking), and the ability to archive outgoing messages. I am not recommending one method over another.



To open a new window or not?

To open a new window or not? 5 reasons to re-consider this web technique By Tiffany B. Brown Published: 20040214 Downloaded from: http://tiffanybbrown.com/articles/viewarticle.php/58 Questions, comments and feedback: http://www.tiffanybbrown.com/contact/ At the newspaper site I work for (ajc.com), our style is to open external links in a new window. It's a pretty standard web convention. Yahoo! mail and Hotmail.com do it. Most newspaper sites do it. Heck, I've even done it on my own site. But based on accessibility standards and my own experience as a user, I wonder if opening new windows for external links causes more problems and confusion than it prevents. Traditional Internet wisdom holds that opening external links in a new window does three things: It keeps users from leaving your site entirely. Your site remains just a closed window away. It keeps users from losing their place. Again: close the new window and there you are. It underlines the point that this site is not controlled or maintained by your organization, and that the user is no longer on your site. I think it's time, however, that we re-evaluate this convention of opening new windows for external links. Here are five reasons to reconsider. Opening new windows sacks user choice. I often visit web sites while doing other tasks, having several windows open at any time. More than once, I have closed the original browser window (or another application) because my browser would hang trying to open a new one. Rather than keeping a user on your site, opening a new window could cause the opposite effect. Opening new windows can confuse users. New Internet users aren't aware of every Internet trick. Opening a new window can cause confusion, especially when browser interface items are rendered useless (discussed in point three), or old windows "disappear" under the new one. Even experienced users might not immediately realize that a new window was opened at first. A third reason not to open new windows: it often kills the back button. And as usability expert Jakob Neilsen says, breaking the back button is the easiest way to cut the user's lifeline, leading to frustration and confusion. Instead of keeping a user's place (which is better kept by the user's mind and his or her browser history), opening new windows can disorient. Four, new windows can cause accessibility problems. Many screen readers can't handle new windows, or don't handle them well. And related to the above point: what if the user has a cognitive disability? Imagine his/her frustration at trying to figure out why the other window has disappeared. Mark Pilgrim makes this point at DiveIntoAccessibility.org. Finally, opening new windows is not valid code &8212; at least, not through the usual means of <a href="http://linkto" target="_blank">. As of HTML 4.01, the target attribute has been deprecated. Two caveats to point 5: the target attribute is still valid in HTML 3.2. It is also possible to open new windows using valid, standard code. But doing so violates World Wide Web Consortium accessibility guidelines. The W3C mailing list archives discusses this topic in greater detail. Internet users -- even newbies -- in my opinion, are now savvy enough to know when they are visiting an external site. Cuing users about where a link will go, however, is a good practice. There are threefour fairly unintrusive ways to do it. Use language and context. Tell users that they are about to visit another site in the sentence. For example: "Read more about accessibility from the World Wide Web Consortium web site." Use CSS classes. Create separate styles for internal and external links. For example, internal links might be red: (a.internal{color:#ff0000;}) while external links are green (a.external{color:#006600;}). Or you can make internal links underlined while external links have a border. Something to consider with color cues: they mean little or nothing to people who can't see them; as much as 10 percent of men have some degree of colorblindness (WebAIM discusses pitfalls of color use). Use the title attribute of the <a> element to tell users where the link will take them. When a user mouses over the link, he or she will get a little blurb of text explaining where the link goes. For example:<a href="http://linkto" title="Link goes nowhere"> produces:Fake linkMouse over the above link to see an example. Another solution is to offer an "Open external links in new windows" feature. The advantages of offering this option are twofold. It gives users a choice. It saves users a step. They won't need to copy and paste the U R I or right-click their mouse to open a new window. Adrian Holovaty does a good job of this on his site. Don't forget to use the <label for=""> element and attribute around the text for your check box. Conclusion Instead of impeding on the user's experience, let the user decide whether (s)he wants to use another window for an external site. Why risk alienating your user when there are other ways to distinguish external links? Top



target in xhtml11

Re: target in xhtml11This message: [ Message body ] [ Respond ] [ More options ] Related messages: [ Next message ] [ Previous message ] [ In reply to ] [ Next in thread ] [ Replies ] From: Beton, Richard <richard.beton@roke.co.uk> Date: Mon, 14 Jun 2004 14:15:23 +0100To: dekoder@z.pl, www-validator@w3.org Message-ID: <40CDA4EB.2090607@roke.co.uk> Piotr 'dekoder' Rybałtowski wrote: >Hello!>>Sience there's no target attribute in xhtml 1.1 what can I use to get>target="_blank" effect known from html and xhtml transitional? Only>javascript can help?>  > Some options: 1. Use XHTML 1.0 2. Use Javascript 3. Make up your own DTD based on XHTML 1.1 modularisation 4. Don't use target at all. To pick up 4 first, there's a school of thought that opening new windows is considered unkind to the user.  I'm not sure what I think of this, having read arguments for and agains this premise. On my own website, I have gradually reduced, but not eliminated, the new-window opening, but I may do so at some future date.. Option 3 may be the glitzy new way forward, but I worry that it may open a can of worms of incompatibilities so I wouldn't recommend it just yet.  [for the curious, I had a play with it: see http://www.whr.co.uk/dtd/xhtml11+target.dtd for my attempt]. Option 1 - I wouldn't recommend a backward step like this, but it is one of the options.I have to confess I don't understand why many experts say don't use XHTML1.1 (some people even deprecate XHTML completely). This seems to me like saying that we shouldn't use new standards just because one popular browser doesn't support them yet. As it happens, IE happily pretends XHTML is HTML so that's good enough for me. As long as you use text/html (here's another can of worms).I digress... Finally, option 2: I have picked up bits of Javascript and what follows is I think a reasonably robust way to do it. Firstly the script: /* open a new window - normal decoration (by R.D.Beton) * This replaces the target attribute removed from XHTML 1.1. */function wOpen (url, name){  w = window.open (url.href, name, "directories=yes,location=yes,menubar=yes,resizable=yes,scrollbars=yes,status=yes,toolbar=yes");  w.focus();  return false;} wOpen returns false just for the convenience of the call. And now the call itself: <a href="http://www.w3.org" onclick="return wOpen(this, '_blank')">W3.org</a> Note that the href attribute supplies the URL which the Javascript uses.  If Javascript is disabled, the normal href works instead, i.e. replacing the current window rather than opening a new one. I'll end by repeating my nervousness about opening new windows and recommend you try reading up before deciding what to do (e.g. http://www.tiffanybbrown.com/articles/viewarticle.php/58, http://www.classy.dk/log/archive/000870.html) Rickhttp://www.whr.co.uk/  



» 1 »

发表评论:
昵称:
密码:
主页:
标题:
验证码:  (不区分大小写,请仔细填写,输错需重写评论内容!)

日历 | CALENDAR

«August 2020»
1
2345678
9101112131415
16171819202122
23242526272829
3031
blog名称:World Wide Web Watch
日志总数:193
评论数量:664
留言数量:75
访问次数:5788627
建立时间:2004年10月30日
站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.047 second(s), page refreshed 144429243 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》
苏ICP备05006046号