Ornamental href question
I have a question about how to handle links which have a JavaScript action in the onclick but do not navigate to another page. This would be a link which toggles the display of something on the page, for example. I am wondering what the best thing to do with the href is. ( I have left out titles to simplify this example.)
<a href="???" onclick="doSomething();">link text</a> or
<a href="???" onclick="doSomething();return false;">link text</a>
href="javascript://return%20false;" or href="javascript://return false;" doesn't work with webkit
What do you use and why?
UPDATE:
I found all the href="javascript://return%20false;" and href="javascript://return false;" and replaced them with href="javascript:void(0);" or href="javascript:void 0;". I found that if the browser got to the href in some cases the javascript in the onclick was actually being voided, or the return being ignored, so it didn't work.
If I added "return false;" on the end of whatever was in the onclick it was fine. If you put "return false" at the end of the onclick to prevent the href being used, it doesn't matter very much what's in the href just so long as the browser never gets there. For my purposes, I wanted to keep the browser from the href, but also wanted to put something in there that wouldn't cause trouble if the browser did get there by accident (the accident being me forgetting to put a "return false" in the onclick. Putting "return false" at the end of an external function didn't work).
I liked href="#null" because it isn't javascript and seemed to work fine. One of my coworkers pointed out that it would mess up SEO because spiders would try to follow and index the bogus anchor. Users could bookmark it too. So #null is out.
href="javascript:;" didn't void anything and didn't seem to cause errors, so that's what I'm using. I'm also adding "return false".
I had read that browsers are supposed to evaluate the onclick before the href. Someone suggested that some browsers might evaluate them in their order of appearance in the link. I have not looked into this much, but in my very limited testing it seems like the onclick does get evaluated first.
Comments
I've never had any issue with the 'void' approach. For design and usability reasons, I definitely would never want to do what the author of the solution you liked to does: Replace a standard UI element such as a checkbox with a toggled pair of images. Jakob Nielsen has some writings on that type of thing that explain better.
And finally, when IE is set to "check every time" for Web content (as you know, a non-standard setting that developers often use to avoid having to explicitly force-refresh), it has problems with showing images. This is most notorious with background images, but I have experienced the same thing with foreground images. In other words, I don't think the 'void' necessarily will have the effect the author describes for the likely 99.9% of users who do not alter that cache default.
About 'void': After a little googling I turned up an entry quoting the creator of JavaScript that seems to verify definitively that 'void' is meant to be used in 'javascript:' pseudo-urls. On the finer points: The parentheses are not needed, as 'void' is a bona fide js operator, and not a method call. Since it's not a method call, I don't agree with the stylistic preference expressed in the Mozilla Developer Center docs on 'void'.
Could this be much ado about void? ;)
A more extensive solution that I sometimes use is that I made a custom function that attaches all desired behaviour (colour of the link, action, hover behaviour) as event-handlers to a stripped anchor:
"A more extensive solution that I sometimes use is that I made a custom function that attaches all desired behaviour (colour of the link, action, hover behaviour) as event-handlers to a stripped anchor: (a id='someId'). This overcomes IE from not recognizing it as an anchor and consequently hover not working. Advantage is that all event-handlers are separated from the html, and there is no bogus href with javascript in the a anymore. But maybe there are other cons, outside the fact it requires more programming."
It's interesting that we both ended up with almost the same solution (href="javascript:" plus or minus a semicolon).
The real-life instance I am using this for has pages with many links with different appearances and behaviors. I am keeping the display of the links (and their hover) in CSS. The markup is generated in an off-line process which determines where the links go and their behavior. I prefer to have the links created with a class (for for appearance) and the actions already in them rather then trying to attach the behavior at runtime. Partly that's just my preference because I like CSS and would rather use it then JavaScript given a choice.