Blue Raja wrote:
<snip>
This can be done with CSS rather than Javascript. Add "cursor:
hand;" to your style tag, eg:
<a style="cursor: hand;" onclick="doStuff();">A former link</a>
<snip>
cursor:hand; is an IE only formulation, the official CSS version is -
cursor:pointer; - but as it is unrecognised by older IE versions a rule
such as:-
..usePointer {
cursor:hand;
cursor:pointer;
}
- can be use. Modern browsers will use the second rule and old IE
versions will ignore the second rules as they will not recognise it.
(Non-IE, standards compliant browsers will not recognise the first so
they will ignore it, only later IE versions would understand both).
An A element without an HREF, NAME or ID is not really an A element
(neither a link nor an anchor) so it would probably make more sense to
be using some other mark-up. In the absence of any context information a
SPAN would be sufficient for the task. A major difference between those
two elements is how thy function with keyboard navigation. But an A
element without an HREF attribute is going to be outside keyboard
navigation anyway (just like a SPAN).
Setting the cursor CSS property in a STYLE attribute means that it would
be used whenever CSS was supported on the browser, but CSS support is
independent from javascript support (except on Netscape 4). The user of
a javascript incapable/disabled browsers that supports CSS would be left
with the impression that the element was supposed to do something
(because of the cursor) but clicking on the element will do nothing. To
avoid the confusion it is generally better to have javascript apply the
CSS so that it is only used when there is a chance that using the
element will actually do something:-
<style onclick="doStuff();"
onmouseover="this.className='usePointer';this.onmo useover=null;">
Not a Link</span>
Though it is difficult to see the resulting element as being a
contribution to a web page when it is not capable of doing anything
(even without the cursor style). As a result it makes most sense to have
the UI widgets that relate to javascript dependent functionality created
with javascript, using - document.write -, - innerHTML - or with W3C DOM
Node creation and insertion techniques (accompanied by appropriate
feature detection to verify that the browser supports the related
functionality). So that the user is never presented with a UI component
that is incapable of delivering whatever it promises to do.
<input type="button"> elements also make good candidate as devices for
triggering javascript dependent functionality where no viable
alternative can be provided, and can be substantially styled on more
recent and co-operative browsers.
Ultimately the simplest approach has go to be using the A element with
an HREF attribute, cancelling the default action associated with the
onclick handler (the navigation) and providing a URL for the HREF that
either re-produces the functionality remotely (using server-side
scripting) or explains, and apologises for, the javascript dependency in
the UI design.
That way you have the desired cursor as a matter of course, viable
keyboard access and an item on the page that makes sense to the user
however it is allowed to work.
Richard.
