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
