[thelist] href=# versus href=JavaScript.....

jeff jeff at members.evolt.org
Mon Mar 12 04:02:14 CST 2001

: From: Anthony Baratta
: Maybe I'm a lunatic, but using a href=#
: instead of href=javascript is a pet peeve
: of mine. I think its the completely wrong
: way to code. The href=# should be banned. ;-)
: Am I (w)right or wrong?

in my personal opinion you are correct.  to me, the hash is intended to be
used for anchors within the page -- not for javascript.

: From: Scott Dexter
: I thought href=# was the more proper of the
: two (considering '#' is used for an inline
: anchor); and --not that this validates the
: statement-- I've watched browsers puke on a
: href=javascript: call, and that's outside the
: cases where javascript is just turned off ...

usually the cases where the browser will puke on javascript: is where the
browser hasn't been instructed how to handle the link properly.  in most
cases where javascript:somefunction() is used as the value of the href
attribute it would be more appropriate to move the function call to the
onClick event handler and return false there as well to cancel the default
action of executing the value of the href attribute.

: From: Ben Henick
: When you write "href='#'" you are saying,
: "move the page so that the anchor called ''
: (an empty string) is at the top of the
: browser window."
: Thus somewhere on your page there needs to be:
: <a name=""></a>
: The few times I've done this I've always
: used the convention #top, so that there's
: no ambiguity.
: The take-no-prisoners approach to this would
: be to write your HREFs to the images (in the
: same menu), and then putting the following
: code behind an onload statement:
: [snipped code sample and explanation]

i think by using named anchors to mask the behavior of the link for non-js
users only confuses the issue.  this is somewhat similar to using a dropdown
menu as a form of navigation.  it was never designed to do that and just
because you can use it for that doesn't mean it's right.

: If you want to be really gnarly, you also put
: the entire 'document.links...' code inside of
: an if statement that only allows it to work
: for browsers that reliably support window.open()...
: note that AOL, WebTV, and several older versions
: of IE3 DON'T support window.open().

while this is true, it's not really necessary.  instead, it'd be more
appropriate to use the return statement in the onclick event handler to call
your window opening function and returning false for those browsers that can
open windows and true for those that cannot.  then, include a target
attribute if you want the link to be opened in a new window.

 onClick="return openWin(this.href, this.target)"
>click here</a>

your openWin() function would look something like this:

function openWin(href, target)
  if(!aol && !webtv && !(some versions of ie3))
    features = 'height=300,width=500';
    myWin = window.open(href, target, features);
    return false;
  return true;

: From: aardvark
: for the *very* few cases where i use JS
: on a link, i prefer to stick it in the
: href instead of an onclick handler for two
: (what i think are) very important reasons:
: - it doesn't force the page to reload or
: scroll all the way to the top (as some
: browsers do)...

by using the return false statement in your onclick event handler you can
just as easily and more reliably prevent that from happening.

: - it shows the user that it's a JS link
: and what the function is, thanks to the
: browser's feature of displaying an href
: in the status bar...

users can get confused easily about what something does based on the status
bar.  most haven't a clue what a particular function does, even if we give
it a really obvious name.  instead, why not tell them in plain english?

 href="JavaScript:// Click to open a new window with beer ads."
 onClick="getBeer(); return false"
>click here</a>

: dig?


: From: rudy
: > From: James
: > The alternative is to place the javascript
: > function call in the href, but this can
: > give you funky results in older or
: > non-JS-enabled browsers, if I recall. The
: > #null approach avoids that.
: that's really interesting
: as the javascript protocol is misunderstood by
: some early browsers, another good html solution
: goes a little further than just one common <a
: name=top></a> target for all such links, and
: makes a separate target for each which is located
: just ahead of where the link is
: for example
:     <a name=foo></a>
:     <h4>Foo</h4>
:     <a href="#foo" onClick=".....">something</a>
:     .
:     <a name=bar></a>
:     <h4>Bar</h4>
:     <a href="#bar" onClick=".....">something</a>
: so that if the page *does* move it doesn't move
: far, and certainly not to the top (or bottom --
: some browsers scan to the end to find an anchor
: that isn't there)

very interesting approach.  you could also combine the two anchors into one
so you're effectively targeting the same spot on the page.  in the end this
comes down to one thing though -- you're implementing a broken solution to
get the desired behavior in a very old browser, namely anything more than
3-4 years old.  in that regard i would not recommend using the technique of
using named anchors as filler for links that execute javascript.

: From: s t e f
: <a href="#" onclick="anyFunction(anyArgs); return false;">link</a>
: [snip]
: Pointing to # is not a double load of
: work for the browser since return false
: forbids it following the link.

true, but...

: More over, pointing to "#" degrades better
: when Javascript is disabled.  Nothing
: happens except a reload.

in actuality, when a browser encounters a url with an anchor in it, it does
not load the page and then reload it to scroll to the named anchor in the
page, if found.  similarly, when you're on a page with named anchors in the
same document and you click a link to a named anchor, it also does not
reload the page.  the browser simply scrolls the document however necessary
to place the named anchor as close to the top of the browser window as

however, this is still not good enough.  it is possible to eliminate this
scrolling for 99.9% of your potential audience by using the techniques i've
espoused in this response.

my own conclusions...

i prefer to move function calls to the onclick event handler for several
reasons -- one of the most important being accessibility.  by pulling it
from the href attribute, i now have the ability to link to a document for
non-js users that gives them the same information js-enabled users are
getting or taking them to a page explaining what they're missing out on and
why it's valuable/necessary/required.  keeping this in mind i run into very
little instances of needing to find something to use as a placeholder in the
href attribute as i'm linking to a valid document.



mailto:jeff at members.evolt.org

More information about the thelist mailing list