I too think this is the best solution. If you have an element that is meant to perform an action, there is no reason for it be an link.

Were you to ask and your href would look like "#something" some of the other listed answers might serve, but: Without the href linking to anything sensible, there is no point in having a href, or even a link altogether. The suggested use of button might do, or use any other element but a link thank links nowhere.

Another advantage of this is that Bootstrap .btn makes buttons and links look exactly the same.

LowPro is really nice for unobtrusive JS if you have a lot of complex behaviors.

The blog entry does not cite the reference as to why javascript:void(0) should be avoided.

The link is (effectively) broken now.

I use javascript: (no semi-colon) because it looks tidiest in the status bar on hover.

This code may cause bad surprises in older IE. At some point it used to break any animation effects with images, including rollovers and even animated gifs: groups.google.com/forum/#!topic/comp.lang.javascript/…

You can always do... javascript:void('Do foo') since void will return undefined regardless, it will give an indicator to the user what clicking will do. Where Do foo can be Delete record X or whatever you like.

In IE8/IE9, I'm unable to remove the 1px "3D" offset in the button's :active state.

@BrennanRoberts Yeah, unfortunately, any styling of buttons is more problematic with IE... I still feel it's probably the most appropriate approach, not that I don't break my own rules on occasion.

Then don't use <button> but an input type=button instead?

@PatrikAffentranger that will have the same issue with older IE versions... I've used the <a href="javascript:void(0)" onclick="...">...</a> method enough that it works... just suggesting that it's less than friendly for declaring intent with markup.

I use a DIV tag. Easy styling, no fuss.

Then use a <clickable> element. Or a <clickabletim> if you prefer. Unfortunately, using a non-standard tag or a plain div might make it difficult for keyboard users to focus the element.

This answer should be up top. If you are having this dilemma, chances are you are actually in need of a button. And IE9 is quickly losing market shares, fortunately, and the 1px active effect should not prevent us to use semantic markup. <a> is a link, it's meant to send you somewhere, for actions we have <button>'s.

This approach restricts the 'link' to a mouse only operation. An anchor can be visited via the keyboard and its 'onclick' event is fired when the enter key is pressed.

Hardcoding colors in your CSS would prevent the browser from using custom colors the user may define, which can be a problem with accessibility.

They boil down to the same thing it's semantics to use a span or an anchor tag. If the page url can only be generated in javascript it makes no difference where it's running from apart from as pointed out anchor tags can use keyboard navigation.

<span>s are not meant to do anything. <A>nchors and <buttons> are used for that!

Using buttons is a better choice here while using a span is not.

I think a span is better than an anchor tag. Anchor tag exists to direct you to its mandatory href attribute. If you're not going to use the href, don't use an anchor. It doesn't restrict the link to mouse only because it isn't a link. It doesn't have a href. It's more like a button but it doesn't post. The span not being meant to do anything is completely invalid. Consider a dropdown menu that activates when you hover. It's probably a combination of spans and divs, performing the function of a button that expands an area on the screen.

@SLC But a <span> is meaningless to a screen reader or accessible browser, no?

Using buttons is often is a terrible idea from design point to trigger show/hide attributes of small divisions of a website, especially if there are plenty of these triggers. Lots of buttons in one place usually looks awful, if this is not some kind of a control panel. And as pointed earlier, anchors too are not designed to be JS triggers. So span or maybe even div looks like a better replacement, with their own downsides, but still better. There is nothing worse in the world than some gibberish in the href attribute. And also span handles middle-click better than anything.

I do this for cases where the user is not being directed somewhere, e.g., opening a modal. It's nice because then the middle button doesn't default to trying to open the link in a new tab. If I have something that navigates the user and they're allowed to open it in a new tab, I use a link (a tag with href) so users can open new tabs easily with middle mouse or ctrl + click. If I have something that navigates the user and I don't want them to open multiple tabs, then the button approach works.

So in user agents with JavaScript enabled and the function supported this run a JavaScript function, falling back (for user agents where the JS fails for whatever reason) to a link to the top of the page? This is rarely a sensible fallback.

"ideally with a real link to follow in case the user has JavaScript disabled", it should be going to a useful page not #, even if it's just an explanation that the site needs JS to work. as for failing, I would expect the developer to use proper browser feature detection, etc before deploying.

I would assume (hope) that something like this would only be for showing a popup or something similarly simple. In that case, the default would be the popup page url. If this is part of a web application, or having JS disabled would totally break the page, then this code has other issues...

My web apps are designed to degrade gracefully, so the link will still be a useful page. Unless your web app is a chat client or something that interactive, this should work if you put in the time to design with degradation in mind.

The issue is if myJsFunc throws an error, it won't be captured for the return false.

The problem with # is that if the javascript doesn't run for some particular reason, it will break, sometimes very badly (eg: if you have a base href on the page, # will usually take the user to a completely different webpage). On the other hand with void(0), if the javascript has a problem it simply won't do anything. Another nice benefit of void(0) is it takes away any necessity for cancelling the click event, which is easily forgotten and makes it impossible to attach multiple observers to the event.

From what I found, you have to use onclick="event.preventDefault(); myJsFunc(); return false;".

@AbhiBeckert Neither is right, the href should contain a URL that can be used as a fallback. Good example is initiating popups with javascript, use the URL from the href to power the popup and when javascript is disabled the link will take you to the page that would have been loaded by your popup as a fallback.

@Lankymart that's nice in theory, but in the real world there are plenty of situations where there is no fallback URL. The "cancel" button on this comment box for example, has no fallback. StackOverflow has chosen not to have a href attribute at all. This makes it invalid according to the HTML spec and also causes some minor bugs in old browsers (they treat it a being an anchor instead of a clickable element).

@AbhiBeckert And that's a compelling reason because? Just because others do it doesn't mean you have to follow suit I stand by opinion and you are entitled to yours.

Personally both @Fczbkk and StevePaulo approaches are better, regardless of whether a link has a hyperlink or not you should accommodate those who are viewing your site without javascript and gracefully de-grade how ever you see fit.

@Lankymart my work is billed to clients at $100 per hour. If I was to make every javascript link on my current project work without javascript, it would cost about $300,000 (there are thousands of links like that). There are not enough people visiting this website to justify the cost. Instead we would simply tell them "oh, that button won't work unless you turn javascript on." and so far we have never had any complaints. I always put a fallback in when practical, but often it simply isn't worth it. As with most things, you should learn the pros/cons of each solution and choose appropriately.

The way to avoid that is to return false in the onclick event handler.

Returning false in the event handler doesn't avoid that if JavaScript the JS doesn't run successfully.

using "#someNonExistantAnchorName" works well because it has nowhere to jump to.

If you have a base href, then # or #something will take you to that anchor on the base href page, instead of on the current page.

Any use of # or void(0) is bad practice and shouldn't be encouraged.

The shebang (#!) does the trick but it's definitely bad practice.

@Neel, any anchor that doesn't actually exist in the document (e.g. #_) does the same trick, with the same drawbacks.

@Neel At the first release of angular the author said something like, "best practices follow necessity," right before he put his script tags at the very bottom of the page.

Actually they don't do the same. # makes you jump to top of the page.

@Berker Yüceer, why CW?

I always open every link in a new tab and this is the reason why I personally hate it when people use the href="javascript:void(0)" method

Sorry disagree why does this answer have so many upvotes? Any use of javascript: should be considered bad practice, obtrusive and doesn't graceful de-grade.

The next two answers are far better and reasonable than this one. Also the first two arguments are invalid because event.preventDefault() is there exactly to prevent default behavior (like jumping to the top of the page in this case) and do a better job at it without all the return false; craziness.

Fast-forward to 2013: javascript:void(0) violates Content Security Policy on CSP-enabled HTTPS pages. One option would be then to use href='#' and event.preventDefault() in the handler, but I don't like this much. Perhaps you can establish a convention to use href='#void' and make sure no element on the page has id="void". That way, clicking a link to non-existing anchor will not scroll the page.

You can use "#" and then bind a click event to all links with "#" as the href. This would be done in jQuery with: $('a[href="#"]').click(function(e) { e.preventDefault ? e.preventDefault() : e.returnValue = false; });

@jakub.g I like the idea of using a generic hashtag the best. How would I go about preventing the url from updating in the browser? That's my only thing about this... Thanks!

@jaminroe good question; this seems to be working for me in modern browsers: window.onhashchange = function (evt) { if(evt.newURL.endsWith("#void")) { history.replaceState(null, null, evt.oldURL); } } Haven't tested with IE, though MDN says it doesn't support evt.newURL and evt.oldURL (at least IE8). replaceState is supported from IE10.

How is the 2nd reason an advantage to the developer? I would not like things to carry on as usual when an error was thrown.

What about just leaving href="" blank like so. I've read that works pretty well, and does in my experience. And it's still valid

web standards: you should only use href if you have a valid url and you should put that url between href"" prior to page load. both of your methods are horrible for accessibility, usability, every other -ility that applies to web dev

This is the best answer, because it actually answers the question. Most of you seem to have missed the "a link that has the sole purpose to run JavaScript code" part. All your jabbering about links in new tabs, graceful degrading, and web dev -ilities is just off topic web standards / best practice panic mongering. Not having a href might be best, but that actually decreases accessibility and can result in other unexpected behaviors.

History lesson: The use of the hash # was a hack to start with. Older browsers (ie IE) wouldn't make A tags clickable without a non-empty HREF attribute, and many elements could never be clickable; hash was the only way to make something clickable and prevent navigation at the same time, since some browsers then also didn't run Javascript yet. No modern (even older IEs that are still in use today) have those problems anymore; so it's better to stick with standards and avoid both of these hacks to do it the standard appropriate way as mentioned in other answers.

@TimoHuovinen href="javascript:void(0)" opens a blank page on middle click, whereas href="#" opens a copy of the current page on middle click. I think the latter is much worse, especially if you're on a heavy page. Note also this happens only in Firefox: jakub-g.github.io/accessibility/onclick

i used 'javascript:void(0)' to prevent onclick page jumps, from here

Why not just not use javascript:void(0) altogether for these cases? Why not just use a data-* attribute and then use querySelector() (or equivalent) and add the event listeners for them?

I had compatibility problem with ie8 and javascript:void(0) onclick did not fired on attached events

This is the worst answer. Use links for links, not javascript. The javascript: pseudo protocol was designed to replace the current document with the value returned from the expression. When the expression used evaluates to an undefined value (as some function calls do), the contents of the current page are not replaced. Regardless, some browsers interpret this as navigation and will enter into a 'navigation' state where GIF animations and plugins (such as movies) will stop and navigational features such as META refresh, assignment to location.href, and image swaps fail.

Of note - in today's world of client-side applications that use client-side routing, using # is often not an option anymore for a no-op.

I have noticed another con of using "javascript:void(0)" in your href as it regards to using Google Analytics or Webtrends. First of all I assume you are using "javascript:void(0)" in your achor tag because it is firing a function that causes some interaction that does not leave the current URL. In my experiences, using "javascript:void(0)" will cause your anchor tag to fire twice which has been brought to my attention by our QA department. As small as an issue it may seem, it makes using "javascript:void(0)" quite an issue for my strict QA dept. Hope this helps someone out.

@MichaelPlotke Glad I don't work with you! A link is a link however you dress it up, it's hacks like this that create more problems then they solve. It's 2016 no one should be using # or javascript:void(0) now it's poor practice whether you want to just run JavaScript or not. It's inaccessible, can cause unexpected behaviours, doesn't gracefully de-grade. It's not "panic mongering" just good sense.

@Lankymart If I could go back in time I wouldn't have written that, certainly not so snarkily. I've changed my views. If you want an element that runs JS on click, don't use a anchor, just attach a handler via JS and CSS it however you'd like. Sorry to all I offended.

@MichaelPlotke Again I fall a foul of not looking at the timestamp...sorry was reading the comments back to front.

"the final return false; will not execute if the called function throws an error." -> This problem is easily solved by using e.preventDefault() at the top, instead of relying on the return value. This has been the best way to do this for years. I am truly baffled why people still go around using return false.

Can you tell me more about the different between href="javascript:void(0)" and href="javascript:;"?

This answer doesn't actually explain why anchor links don't work

Using href="javascript:myFunc()" in Firefox opens a new tab with the text "javascript:myFunc()" in it, instead of executing the function.

Hi Anthony , I would like to ask you from where did you learn JavaScript ? Which resource ? I spend a lot of time on documentation but I don't learn sufficient enough.

Don't use <a> if your sole purpose is just to trigger js code. Use <button> instead.

I noticed that, when I leave a tag without href attribute, the browser will automatically add href="javascript:;" to it. So can we just leave a tag without href instead of adding href="javascript:void(0)" or href="#"?

Use a button, not a span. Buttons naturally fall in the focus order so can be accessed without a mouse / trackpad / etc.

Adding ton Quentin's comment: as currently written, keyboard users won't reach the span element because it is a non-focusable element. That's why you need a button.

You can make it focusable by adding tabindex="0" to the span. That said, using button is better because it gives you the desired functionality for free. To make it accessible using a span you not only need to attach a click handler, but a keyboard event handler that looks for presses of space bar or enter key and then fires the normal click handler. You would also want to change the second CSS selector to .funcActuator:hover, .funcActuator:focus so the fact that the element has focus is apparent.

WOW, thumbs up for this tip. Never knew that you could use the #self for named tags, and avoid the annoying browser behavior of jumping to top of page. Thank you.

For reference, #self doesn't appear to be special. Any fragment identifier that doesn't match the name or id of any element in the document (and isn't blank or "top") should have the same effect.

I usually just use a made up anchor name, but I think I will start doing this to be consistent across my work.

I suggested establishing #void convention in the other comment but actually #self is as short and easy to memorize. Anything is better than #

But if you click that link it will be weird to the user to see "#void" in the url, looks like and error or bug, same with #self or whatever.

Also if you were to replace an a with a span, you'll need to remember to make it focusable via keyboard.

Be careful, leaving href attributes off is not cross browser compatible and you will lose out on things such as hover effects in internet explorer

I tend to agree with this answer, but there is another issue that arises from omitting the href attribute. In many browsers if you click the link multiple times very quickly it will actually select text on the page. Setting the href solves that particular problem which is not easy to fix otherwise.

Beware: the link-styled button approach suggested here is plagued by the unavoidable "3d" active state in IE9 and lower.

I find this answer to be overly dogmatic. There are times when you just want to apply the JS behavior to 1 or 2 a href's. In that case it's overkill to define extra CSS and inject a whole JS function. In some cases (e.g. adding content via a CMS) you are actually not allowed to inject new CSS or standalone JS, and inline is all you can do. I don't see how the inline solution is any less maintainable in practice for 1 or 2 simple JS a href's. Always be suspicious of broad general statements on bad practice, including this one :)

It would make more sense to add 2 classes, one called cancel and the other action, then apply the css only to .action and the javascript only to .action.cancel

A full disagree here. While I also promote unobtrusive JavaScript, an anchor that has a "javascript:;" and it's actual events bound somewhere else is not bad practice. And it is always better than leaving the attribute out completely.

With all those "notes" that are hard to solve (setting a tabindex is asking for trouble on a complex page!). Far better to just do javascript:void(0). That is the pragmatic answer, and the only sensible answer in the real world.

If you care about making your web application accessible (and you should), simplicity and sanity argues for href. Madness lies in the direction of tabindex.

The missing href attribute is a problem. Many browsers don't display the link mouse cursor (yes, it can be added in CSS, but this is complicating things already) and I've seen some accessibility software ignore links without href (they are treated as just text). This answer has good ideas but the real world isn't as neat.

No, no, no!!! Don't EVER do this! You have just killed accessibility. Users with screen readers will no longer be able to use your application.

I'm agreeing with my two pre-posters. Without the href you are not even able to navigate through the links by using tabs. This answer should be deleted!

According to sitepoint.com/community/t/anchors-without-href/6690/4 Screen-readers are fine with anchors that don't use href. The use of "#" is actually worse as it adds open in new tab functionality which only sends the use back to the original page at the top without the desired functionality.

This actually seems like a very good solution, thanks. I've replaced href="#" with role="button" everywhere and then stuck *[role="button"] { cursor:pointer; } in the CSS and that seems to work very well without the need for unnecessary JS :)

As others have said, this cannot be activated using the keyboard.

This is bad, particularly in IE (up to version 10, not sure about 11). Clicking a link with an empty href results in an unnecessary (and probably unwanted) request being fired, and in IE, it attempts to open Windows Explorer.

@squidbe: This was an old answer but I think that depends on how your JS is written. If you didn't want that to fire, I think you would onclick="return run_foo()" and have run_foo return false or just add a return false line after the function is called. The point of this answer was that you could remove href tags when JS is enabled. The ideal solution would be to populate the href with a fail-safe link most likely to a server-side rendered page href="render/full_page.script?arg=value" onclick="loadAJAXContent.call(this); return false"

You are correct about the fail-safe solution. My point was that the href attribute value is not intended to ever be an empty string, and setting it to empty can cause unwanted side effects. Even when you return false, if there are errors in your script, the undesired request and undesired Windows behavior still occur. If the option is between leaving the hash in the href and removing it via script, I think it's better to leave it.