I tackled this problem with a history manager and the hash. So a user
could actually bookmark a particular page or open a link directly by
middle clicking and associate some javascript with a particular hash.
It has worked extremely well thus far and the project that I did this
on should launch soon. I based the history manager on the unFocus
History Keeper. I will publish the work soon ... just haven't had
time.

Brandon

On 8/16/06, Sam <[EMAIL PROTECTED]> wrote:
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

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Reply via email to