VK wrote:
Csaba Gabor wrote: VK wrote: <a href="http://www.google.com"
accesskey="t"
onfocus="location.href=this.href">Test</a>
That covers both. Ahem. Let's hope the users are not fans of the tab key. If they are,
they are in for a bit of a surprise.
Links are included into taborder by default,
In some browsers, not others. In some it is a preference setting.
Your method also has the drawback that, having navigated to the new URL,
if the 'back' button is used, the link is still in focus so you go
straight back to the new URL.
Very user-unfriendly.
... so navigation by tab doesn't affect the above method. No surprise.
Big surprise really. Suppose you are tabbing to some other link and on
the way put focus on an 'auto navigate' link - use the back button or
key combo to go back - WTF? You're stuck at the new URL.
Not to mention clicking on the
link and moving the mouse away before releasing the button.
"Click" is defined as the sequence of "mousedown"-"mouseup" events on
the same point. So the event above is not clicking and the navigation
by link is not presumed - moreover must be prevented.
You're right, it's not a click, it's a drag. You completely missed the
point though.
Your solution isn't based on a click, it's based on focus. It will
still navigate to the new URL even though it did not receive a click
event because the link keeps focus.
The whole purpose of dragging a link would be to drop it elsewhere (new
tab, page whatever) and leave the current page at the current URL. But
your method leaves both windows at the new URL.
Really, really user-unfriendly.
--
Rob