I agree with the issues you describe below. These are real-world problems when designing web pages for general audiences.
I doubt the inventors of "open in tab" and "open in new window" could foresee these issues. Sam > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Gregory > Sent: Wednesday, August 16, 2006 12:02 PM > To: rails-spinoffs@lists.rubyonrails.org > Subject: Re: [Rails-spinoffs] Completely off-topic, so flame me > > I think you've misunderstood part of what I'm trying to say. (Sample > file below.) > > On Firefox 1.5/OS X and Firefox 1.5/WinXP > > 1. When middle-clicking (or right-clicking and selecting "Open link > in new tab"), > a. The javascript does NOT fire, and > b. The link opens in a new tab. > > So, if href="#", it opens a duplicate page, if href="javascript:void > (0);" it opens a blank tab. > > 2. Oddly, when <alt>-clicking (to open in a new tab) > a. The javascript DOES execute, and > b. The link still opens in a new tab. > > In other words, as a Firefox user, I will often middle click on > something that looks like a link--and the web app will not behave as > I expect it to. Hence my suggestion to not use an href (and thus an > <a> tag) at all if you're trapping the onclick event but not linking > anywhere. I'd also suggest trying to find a way to either > make it not > look like a link but still look clickable (is that a paradox?) or > differentiate it visually somehow. It's not just about "unobtrusive > Javascript" or "HIJAX," it's about behavior violating a user's > expectations. > > For added fun, try middle-clicking on "Link 3" in Firefox. > > On Safari 2.0, both when middle-clicking and <cmd>-clicking, and IE/ > WinXP when <ctrl>- or <shift>-clicking, the javascript executes, but > no new link/tab/window opens. (What I believe is expected > behavior.) > For both Safari and IE, right-clicking and selecting "Open link in > new tab/window" does not execute the js, and opens the link in the > new tab/window. > > > -- TAG > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/ > TR/html4/strict.dtd"> > <html> > <head> > <title></title> > <script type="text/javascript"> > //<![CDATA[ > var Debug = { > print: function (str) { > if (!this.debug) {this.debug = > document.getElementById("debug");} > this.debug.innerHTML += str; > }, > println: function (str) {this.print(str + "<br />\n");} > } > > var Event = { > stop: function(event) { > if (event.preventDefault) { > event.preventDefault(); > event.stopPropagation(); > } else { > event.returnValue = false; > event.cancelBubble = true; > } > } > } > > function click2() { > var e = window.event; > if (!e) {Debug.println("No event"); return false;} > Event.stop (e); > return false; > } > > function click3(e) { > Debug.println('Link 3 clicked'); > if (!e) {e = window.event}; > if (!e) {Debug.println("No event"); return false;} > Event.stop (e); > return false; > } > > window.onload = function () { > var el = document.getElementById("link3"); > el.onclick = click3; > } > //]]> > </script> > <style type="text/css"> > #link3 { > color:blue; > text-decoration: underline; > } > </style> > </head> > <body> > <ol> > <li><a href="#" onclick="Debug.println('Link 1 clicked'); return > false;">Link 1</a></li> > <li><a href="javascript:void(0);" onclick="Debug.println('Link 2 > clicked'); return click2();">Link 2</a></li> > <li><span id="link3">Link 3</span></li> > </ol> > <pre id="debug"></pre> > </body> > </html> > > > On Aug 15, 2006, at 12:47 PM, Sam wrote: > > >> Exactly that is also my problem. Oky not mine but also a > >> customer of mine > >> wants the shift click. > >> Statement: Shift click does the same as click but opens in new > >> window" > >> Problem: I have some functionality that changes a area you > could name > >> display-area. The customer now argues that he expects the > >> display-area in a > >> new window. > > > > My thoughts: > > > > - Thomas' statement: when onclick returns *false*, the href isn't > > taken. > > That solves many problems and I think was overlooked by > critics of the > > href=# option. > > > > - href="#" won't go to the top of page if onclick returns false, > > however, > > href="javascript:void(0)" won't go anywhere no matter what the > > onclick event > > handler returns. > > > > - IE will open a window in any case if the SHIFT key is held > > down. I've > > found no way to suppress this, except perhaps > > href="javascript:window.close" > > ;-) (think of the downside to this) > > > > - Regarding the overuse of links to reach an event handler: I am > > one of > > those coders who overuses links for onclick items which do > not need > > to be > > "links". I do this believing it will be better for a > screen reader to > > understand. I may be off on this, but a screen reader "knows" a > > link is > > clickable. I'm not sure it knows an <img> is clickable, > especially > > if the > > onclick is assigned dynamically. > > > > - Regarding comments on designing links which behave well when > > JavaScript > > isn't enabled: Some webs (e.g., the stuff we write) are run > > completely > > wrapped in a JavaScript portal, a.k.a. "Learning Management System". > > Designing links to perform favorably if JavaScript isn't enabled > > don't apply > > to our development work. The entire LMS would not run if > > JavaScript were > > not enabled. > > > > > > > > > > > > _______________________________________________ > > Rails-spinoffs mailing list > > Rails-spinoffs@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
