Ccna final exam - java, php, javascript, ios, cshap all in one. This is a collaboratively edited question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
Friday, May 25, 2012
Href for JavaScript links: "#' or "javascript:void(0)'?
When building a link that has the sole purpose to run JavaScript code, is it better to
Three reasons. Encouraging the use of # amongst a team of developers inevitably leads to some using the return value of the function called like this:
function doSomething() { //Some code return false; }
But then they forget to use return doSomething() in the onclick and just use doSomething().
A second reason for avoiding # is that the final return false; will not execute if the called function throws an error. Hence the developers have to also remember to handle any error appropriately in the called function.
A third reason is that there are cases where the onclick event property is assigned dynamically. I prefer to be able to call a function or assign it dynamically without having to code the function specifically for one method of attachment or another. Hence my onclick (or on anything) in HTML markup look like this:
onclick="someFunc.call(this)"
OR
onclick="someFunc.apply(this, arguments)"
Using javascript:void(0) avoids all of the above headaches, and I haven't found any examples of a downside.
So if you're a lone developer then you can clearly make your own choice, but if you work as a team you have to either state:
Use href="#", make sure onclick always contains return false; at the end, that any called function does not throw an error and if you attach a function dynamically to the onclick property make sure that as well as not throwing an error it returns false.
If you can have an actual URL that makes sense use that as the HREF. The onclick won't fire if someone middle-clicks on your link to open a new tab or if they have JavaScript disabled.
If that is not possible, then you should at least inject the anchor tag into the document with JavaScript and the appropriate click event handlers.
I realize this isn't always possible, but in my opinion it should be striven for in developing any public website.
Check out Unobtrusive JavaScript and Progressive enhancement (both Wikipedia).
The first one, ideally with a real link to follow in case the user has JavaScript disabled. Just make sure to return false to prevent the click event from firing if the JavaScript executes.
HREFs THAT DO NOTHING ARE BAD PRACTICE! STOP DOING THAT!
Doing <a href="#" onclick="myJsFunc();">Link</a> or <a href="javascript:void(0)" onclick="myJsFunc();">Link</a> or whatever else that contains an onclick attribute, or a href attribute that does nothing was okay back five years ago, though now it is considered incredibly bad practice. Here's why:
It promotes the bad practice of obtrusive JavaScript - which has turned out to be difficult to maintain and difficult to scale. More on this in Unobtrusive JavaScript. You're spending your time writing incredibly overly verbose code - which has very little (if any) benefit to your codebase. There are now better, easier, and more maintainable and scalable ways of accomplishing the desired result.
A better way: unobtrusive JavaScript
Just don't have a href attribute at all! Any good CSS reset would take care of the missing default cursor style, so that is a non-issue. Then attach your JavaScript functionality using graceful and unobtrusive best practices - which are more maintainable as your JavaScript logic stays in JavaScript, instead of in your markup - which is essential when you start developing large scale JavaScript applications which require your logic to be split up into blackboxed components and templates. More on this in Large-scale JavaScript Application Architecture)
// Hover shim for Internet Explorer 6 and Internet Explorer 7. $(document.body).on('hover','a',function(){ $(this).toggleClass('hover'); });
A blackboxed Backbone.js example
For a scalable, blackboxed, Backbone.js component example - see this working jsfiddle example here. Notice how we utilize unobtrusive JavaScript practices, and in a tiny amount of code have a component that can be repeated across the page multiple times without side-effects or conflicts between the different component instances. Amazing!
Notes
Omitting the href attribute on the a element will cause the element to not be accessible using tab key navigation. If you wish for those elements to be accessible via the tab key, then the ideal solution would be to use button elements instead. You can easily style button elements to look like normal links as mentioned in Tracker1's answer. Omitting the href attribute on the a element will cause Internet Explorer 6 and Internet Explorer 7 to not take on the a:hover styling, which is why we have added a simple JavaScript shim to accomplish this via a.hover instead. Which is perfectly okay, as if you don't have a href attribute and no graceful degradation then your link won't work anyway - and you'll have bigger issues to worry about. If you want your action to still work with JavaScript disabled, then using an a element with a href attribute that goes to some URL that will perform the action manually instead of via an Ajax request or whatever should be the way to go. If you are doing this, then you want to ensure you do an event.preventDefault() on your click call to make sure when the button is clicked it does not follow the link. This option is called graceful degradation.
If your "link" has the sole purpose of running some JavaScript code it doesn't qualify as a link; rather a piece of text with a JavaScript function coupled to it. I would recommend to use a <span> tag with an onclick handler attached to it and some basic CSS to immitate a link. Links are made for navigation, and if your JavaScript code isn't for navigation it should not be an <a> tag.
Or, even better, you'd have the default action link in the HTML, and you'd add the onclick event to the element unobtrusively via JavaScript after the DOM renders, thus ensuring that if JavaScript is not present/utilized you don't have useless event handlers riddling your code and potentially obfuscating (or at least distracting from) your actual content.
I agree with suggestions elsewhere stating that you should use regular URL in href attribute, then call some JavaScript function in onclick. The flaw is, that they automaticaly add return false after the call.
The problem with this approach is, that if the function will not work or if there will be any problem, the link will become unclickable. Onclick event will always return false, so the normal URL will not be called.
There's very simple solution. Let function return true if it works correctly. Then use the returned value to determine if the click should be cancelled or not:
JavaScript
function doSomething() { alert( 'you clicked on the link' ); return true; }
Note, that I negate the result of the doSomething() function. If it works, it will return true, so it will be negated (false) and the path/to/some/URL will not be called. If the function will return false (for example, the browser doesn't support something used within the function or anything else goes wrong), it is negated to true and the path/to/some/URL is called.
Unless you're writing out the link using JavaScript (so that you know it's enabled in the browser), you should ideally be providing a proper link for people who are browsing with JavaScript disabled and then prevent the default action of the link in your onclick event handler. This way those with JavaScript enabled will run the function and those with JavaScript disabled will jump to an appropriate page (or location within the same page) rather than just clicking on the link and having nothing happen.
Definitely hash (#) is better because in JavaScript it is a pseudoscheme:
pollutes history instantiates new copy of engine runs in global scope and doesn't respect event system.
Of course "#" with an onclick handler which prevents default action is [much] better. Moreover, a link that has the sole purpose to run JavaScript is not really "a link" unless you are sending user to some sensible anchor on the page (just # will send to top) when something goes wrong. You can simply simulate look and feel of link with stylesheet and forget about href at all.
In addition, regarding cowgod's suggestion, particularly this: ...href="javascript_required.html" onclick="... This is good approach, but it doesn't distinguish between "JavaScript disabled" and "onclick fails" scenarios.
You should always strive for graceful degradation (in the event that the user doesn't have JavaScript enabled...and when it is with specs. and budget). Also, it is considered bad form to use JavaScript attributes and protocol directly in HTML.
This way you can assign your onclick. I also suggest binding via script, not using the onclick attribute on the element tag.
If you MUST use an A element, use javascript:void(0); for reasons already mentioned.
Will always intercept in case your onclick event fails. Will not have errant load calls happen, or trigger other events based on a hash change
I've seen using the hash tag cause unexpected behavior, and it's best to avoid it unless you intend to use it, and are allowing the click to happen, then binding to the hash tag for interaction changes/history.
Depending on what you want to accomplish, you could forget the onclick and just use the href:
<a href="javascript:myJsFunc()">Link Text</a>
It gets around the need to return false. I don't like the # option because, as mentioned, it will take the user to the top of the page. If you have somewhere else to send the user if they don't have JavaScript enabled (which is rare where I work, but a very good idea), then Steve's proposed method works great.
Lastly, you can use javascript:void(0) if you do not want anyone to go anywhere and if you don't want to call a JavaScript function. It works great if you have an image you want a mouseover event to happen with, but there's not anything for the user to click on.
If you're using a link with onclick for navigation, don't use href="#" as the fallback when JavaScript is off. It's usually very annoying when the user clicks on the link. Instead, provide the same link the onclick handler would provide if possible. If you can't do that, skip the onclick and just use a JavaScript URI in the href.
make href simple, search engines need it. If you use any other stuff(string), may cause 404 error. when mouse hover on it, do not shown it is a script use return false, then page not jump to top, or break back-button
Just to pick up the point some of the other have mentioned.
It's much better to bind the event 'onload'a or $('document').ready{}; then to put JavaScript directly into the click event.
In the case that JavaScript isn't available, I would use a href to the current URL, and perhaps an anchor to the position of the link. The page is still be usable for the people without JavaScript those who have won't notice any difference.
As I have it to hand, here is some jQuery which might help:
var [functionName] = function() { };
jQuery("[link id or other selector]").bind("click", [functionName]);
Ideally you should have a real URL as fallback for non-JavaScript users.
If this doesn't make sense, use # as the href attribute. I don't like using the onclick attribute since it embeds JavaScript directly in the HTML. A better idea would be to use an external JS file and then add the event handler to that link. You can then prevent the default event so that the URL doesn't change to append the # after the user clicks it.
What I understand from your words is that you want to create a link just to run JavaScript code.
Then you should consider that there are people who blocks JavaScript out there in their browsers.
So if you are really going to use that link only for running a JavaScript function then you should add it dynamically so it won't be even seen if the users didn't enable their JavaScript in the browser and you are using that link just to trigger a JavaScript function which makes no sense to use a link like that when JavaScript is disabled in the browser.
For that reason neither of them is good when JavaScript is disabled.
Aand if JavaScript is enabled and you only want to use that link to invoke a JavaScript function then
because href="#" is going to cause the page to do actions that are not needed.
Also, another reason why <a href="javascript:void(0)" onclick="myJsFunc();">Link</a> is better than <a href="#" onclick="myJsFunc();">Link</a> is that JavaScript is used as the default scripting language for most of the browsers. As an example Internet Explorer, uses an onclick attribute to define the type of scripting language that would be used. Unless another good scripting language pops up, JavaScript will be used by Internet Explorer as the default too, but if another scripting language used javascript:, it would let Internet Explorer to understand which scripting language is being used.
Considering this, I would prefer using and exercising on
I believe you are presenting a false dichotomy. These are not the only two options.
I agree with Mr. D4V360 who suggested that, even though you are using the anchor tag, you do not truly have an anchor here. All you have is a special section of a document that should behave slightly different. A tag is far more appropriate.
It's nice to have your site be accessible by users with JavaScript disabled, in which case the href points to a page that performs the same action as the JavaScript being executed. Otherwise I use "#" with a "return false;" to prevent the default action (scroll to top of the page) as others have mentioned.
Googling for "javascript:void(0)" provides a lot of information on this topic. Some of them, like this one mention reasons to NOT use void(0).
I strongly prefer to keep my JavaScript out of my HTML markup as much as possible. If I'm using <a> as click event handlers then I'd recommend using <a class="trigger" href="#">Click me!</a>.
$('.trigger').click(function (e) { e.preventDefault(); // Do stuff... });
It's very important to note that many developers out there believe that using anchor tags for click-event handlers isn't good. They'd prefer you to use a <span> or <div> with some CSS that adds cursor: pointer; to it. This is a matter if much debate.
Usually, you should always have a fall back link to make sure that clients with JavaScript disabled still has some functionality. This concept is called unobtrusive JavaScript. Example... Let's say you have the following search link:
<a href="search.php" id="searchLink">Search</a>
You can always do the following:
var link = document.getElementById('searchLink');
link.onclick = function() { try { // Do Stuff Here } finally { return false; } };
That way, people with JavaScript disabled are directed to search.php while your viewers with JavaScript view your enhanced functionality.
There is one more important thing to remember here. Section 508 compliance. Because of it, I feel it's necessary to point out that you need the anchor tag for screen readers such as JAWS to be able to focus it through tabbing. So the solution "just use JavaScript and forget the anchor to begin with" is not an option for some of this. Firing the JavaScript inside the href is only necessary if you can't afford for the screen to jump back up to the top. You can use a settimeout for 0 seconds and have JavaScript fire to where you need focus but even the apage will jump to the top and then back.
Don't lose sight of the fact that your URL may be necessary -- onclick is fired before the reference is followed, so sometimes you will need to process something clientside before navigating off the page.
I use javascript:void(0).
ReplyDeleteThree reasons. Encouraging the use of # amongst a team of developers inevitably leads to some using the return value of the function called like this:
function doSomething() {
//Some code
return false;
}
But then they forget to use return doSomething() in the onclick and just use doSomething().
A second reason for avoiding # is that the final return false; will not execute if the called function throws an error. Hence the developers have to also remember to handle any error appropriately in the called function.
A third reason is that there are cases where the onclick event property is assigned dynamically. I prefer to be able to call a function or assign it dynamically without having to code the function specifically for one method of attachment or another. Hence my onclick (or on anything) in HTML markup look like this:
onclick="someFunc.call(this)"
OR
onclick="someFunc.apply(this, arguments)"
Using javascript:void(0) avoids all of the above headaches, and I haven't found any examples of a downside.
So if you're a lone developer then you can clearly make your own choice, but if you work as a team you have to either state:
Use href="#", make sure onclick always contains return false; at the end, that any called function does not throw an error and if you attach a function dynamically to the onclick property make sure that as well as not throwing an error it returns false.
OR
Use href="javascript:void(0)"
The second is clearly easier to communicated.
Neither.
ReplyDeleteIf you can have an actual URL that makes sense use that as the HREF. The onclick won't fire if someone middle-clicks on your link to open a new tab or if they have JavaScript disabled.
If that is not possible, then you should at least inject the anchor tag into the document with JavaScript and the appropriate click event handlers.
I realize this isn't always possible, but in my opinion it should be striven for in developing any public website.
Check out Unobtrusive JavaScript and Progressive enhancement (both Wikipedia).
The first one, ideally with a real link to follow in case the user has JavaScript disabled. Just make sure to return false to prevent the click event from firing if the JavaScript executes.
ReplyDelete<a href="#" onclick="myJsFunc(); return false;">Link</a>
'#' will take the user back to the top of the page, so I usually go with void(0).
ReplyDeleteHREFs THAT DO NOTHING ARE BAD PRACTICE! STOP DOING THAT!
ReplyDeleteDoing <a href="#" onclick="myJsFunc();">Link</a> or <a href="javascript:void(0)" onclick="myJsFunc();">Link</a> or whatever else that contains an onclick attribute, or a href attribute that does nothing was okay back five years ago, though now it is considered incredibly bad practice. Here's why:
It promotes the bad practice of obtrusive JavaScript - which has turned out to be difficult to maintain and difficult to scale. More on this in Unobtrusive JavaScript.
You're spending your time writing incredibly overly verbose code - which has very little (if any) benefit to your codebase.
There are now better, easier, and more maintainable and scalable ways of accomplishing the desired result.
A better way: unobtrusive JavaScript
Just don't have a href attribute at all! Any good CSS reset would take care of the missing default cursor style, so that is a non-issue. Then attach your JavaScript functionality using graceful and unobtrusive best practices - which are more maintainable as your JavaScript logic stays in JavaScript, instead of in your markup - which is essential when you start developing large scale JavaScript applications which require your logic to be split up into blackboxed components and templates. More on this in Large-scale JavaScript Application Architecture)
Simple code example
Your HTML:
<a class="cancel-action">Cancel this action</a>
Your CSS:
a { cursor: pointer; color: blue; }
a:hover,a.hover { text-decoration: underline; }
Your JavaScript:
// Cancel click event
$('.cancel-action').click(function(){
});
// Hover shim for Internet Explorer 6 and Internet Explorer 7.
$(document.body).on('hover','a',function(){
$(this).toggleClass('hover');
});
A blackboxed Backbone.js example
For a scalable, blackboxed, Backbone.js component example - see this working jsfiddle example here. Notice how we utilize unobtrusive JavaScript practices, and in a tiny amount of code have a component that can be repeated across the page multiple times without side-effects or conflicts between the different component instances. Amazing!
Notes
Omitting the href attribute on the a element will cause the element to not be accessible using tab key navigation. If you wish for those elements to be accessible via the tab key, then the ideal solution would be to use button elements instead. You can easily style button elements to look like normal links as mentioned in Tracker1's answer.
Omitting the href attribute on the a element will cause Internet Explorer 6 and Internet Explorer 7 to not take on the a:hover styling, which is why we have added a simple JavaScript shim to accomplish this via a.hover instead. Which is perfectly okay, as if you don't have a href attribute and no graceful degradation then your link won't work anyway - and you'll have bigger issues to worry about.
If you want your action to still work with JavaScript disabled, then using an a element with a href attribute that goes to some URL that will perform the action manually instead of via an Ajax request or whatever should be the way to go. If you are doing this, then you want to ensure you do an event.preventDefault() on your click call to make sure when the button is clicked it does not follow the link. This option is called graceful degradation.
Neither if you ask me;
ReplyDeleteIf your "link" has the sole purpose of running some JavaScript code it doesn't qualify as a link; rather a piece of text with a JavaScript function coupled to it. I would recommend to use a <span> tag with an onclick handler attached to it and some basic CSS to immitate a link. Links are made for navigation, and if your JavaScript code isn't for navigation it should not be an <a> tag.
Example:
<style type="text/css">
.jsAction {
cursor: pointer;
color: #00f;
text-decoration: underline;
}
</style>
<p>I want to call a JavaScript function <span class="jsAction" onclick="callFunction();">here</span>.</p>
Ideally you'd do this:
ReplyDelete<a href="javascriptlessDestination.html" onclick="myJSFunc(); return false;">Link text</a>
Or, even better, you'd have the default action link in the HTML, and you'd add the onclick event to the element unobtrusively via JavaScript after the DOM renders, thus ensuring that if JavaScript is not present/utilized you don't have useless event handlers riddling your code and potentially obfuscating (or at least distracting from) your actual content.
I agree with suggestions elsewhere stating that you should use regular URL in href attribute, then call some JavaScript function in onclick. The flaw is, that they automaticaly add return false after the call.
ReplyDeleteThe problem with this approach is, that if the function will not work or if there will be any problem, the link will become unclickable. Onclick event will always return false, so the normal URL will not be called.
There's very simple solution. Let function return true if it works correctly. Then use the returned value to determine if the click should be cancelled or not:
JavaScript
function doSomething() {
alert( 'you clicked on the link' );
return true;
}
HTML
<a href="path/to/some/url" onclick="return !doSomething();">link text</a>
Note, that I negate the result of the doSomething() function. If it works, it will return true, so it will be negated (false) and the path/to/some/URL will not be called. If the function will return false (for example, the browser doesn't support something used within the function or anything else goes wrong), it is negated to true and the path/to/some/URL is called.
Unless you're writing out the link using JavaScript (so that you know it's enabled in the browser), you should ideally be providing a proper link for people who are browsing with JavaScript disabled and then prevent the default action of the link in your onclick event handler. This way those with JavaScript enabled will run the function and those with JavaScript disabled will jump to an appropriate page (or location within the same page) rather than just clicking on the link and having nothing happen.
ReplyDeleteIt would be better to use jQuery,
ReplyDelete$(document).ready(function() {
$("a").css("cursor", "pointer");
});
and omit both href="#" and href="javascript:void(0)".
The anchor tag markup will be like
`<a onclick="hello()">Hello</a>`
Simple enough!
Definitely hash (#) is better because in JavaScript it is a pseudoscheme:
ReplyDeletepollutes history
instantiates new copy of engine
runs in global scope and doesn't respect event system.
Of course "#" with an onclick handler which prevents default action is [much] better. Moreover, a link that has the sole purpose to run JavaScript is not really "a link" unless you are sending user to some sensible anchor on the page (just # will send to top) when something goes wrong. You can simply simulate look and feel of link with stylesheet and forget about href at all.
In addition, regarding cowgod's suggestion, particularly this: ...href="javascript_required.html" onclick="... This is good approach, but it doesn't distinguish between "JavaScript disabled" and "onclick fails" scenarios.
# is better than javascript:anything, but the following is even better:
ReplyDeleteHTML:
<a href="/gracefully/degrading/url/with/same/functionality.ext" class="some-selector">For great justice</a>
JavaScript:
$(function() {
$(".some-selector").click(myJsFunc);
});
You should always strive for graceful degradation (in the event that the user doesn't have JavaScript enabled...and when it is with specs. and budget). Also, it is considered bad form to use JavaScript attributes and protocol directly in HTML.
I use
ReplyDelete<a href="javascript:;" onclick="myJsFunc();">Link</a>
instead of
<a href="javascript:void(0)" onclick="myJsFunc();">Link</a>
I recommend using a <button> element instead, especially if the control is supposed to produce a change in the data. (Something like a POST.)
ReplyDeleteIt's even better if you inject the elements unobtrusively, a type of progressive enhancement. (See this comment.)
I would honestly suggest neither. I would use a stylized <button></button> for that behavior.
ReplyDeletebutton.link {
display:inline-block;
position:relative;
background-color: transparent;
cursor: pointer;
border:0;
padding:0;
color:#00f;
text-decoration:underline;
}
This way you can assign your onclick. I also suggest binding via script, not using the onclick attribute on the element tag.
If you MUST use an A element, use javascript:void(0); for reasons already mentioned.
Will always intercept in case your onclick event fails.
Will not have errant load calls happen, or trigger other events based on a hash change
I've seen using the hash tag cause unexpected behavior, and it's best to avoid it unless you intend to use it, and are allowing the click to happen, then binding to the hash tag for interaction changes/history.
Using just "#" makes some funny movements, so I would recommend to use "#self" if you would like to save on typing efforts of "JavaScript bla, bla,".
ReplyDeleteDepending on what you want to accomplish, you could forget the onclick and just use the href:
ReplyDelete<a href="javascript:myJsFunc()">Link Text</a>
It gets around the need to return false. I don't like the # option because, as mentioned, it will take the user to the top of the page. If you have somewhere else to send the user if they don't have JavaScript enabled (which is rare where I work, but a very good idea), then Steve's proposed method works great.
<a href="javascriptlessDestination.html" onclick="myJSFunc(); return false;">Link text</a>
Lastly, you can use javascript:void(0) if you do not want anyone to go anywhere and if you don't want to call a JavaScript function. It works great if you have an image you want a mouseover event to happen with, but there's not anything for the user to click on.
If you use a link as a way to just execute some JavaScript code (instead of using a span like D4V360 greatly suggested), just do:
ReplyDelete<a href="javascript:(function()%7Balert(%22test%22)%3B%7D)()%3B">test</a>
If you're using a link with onclick for navigation, don't use href="#" as the fallback when JavaScript is off. It's usually very annoying when the user clicks on the link. Instead, provide the same link the onclick handler would provide if possible. If you can't do that, skip the onclick and just use a JavaScript URI in the href.
I will use
ReplyDelete`<a href="#" onclick="myJsFunc();return false">Link</a>`
Reasons:
make href simple, search engines need it. If you use any other stuff(string), may cause 404 error.
when mouse hover on it, do not shown it is a script
use return false, then page not jump to top, or break back-button
Just to pick up the point some of the other have mentioned.
ReplyDeleteIt's much better to bind the event 'onload'a or $('document').ready{}; then to put JavaScript directly into the click event.
In the case that JavaScript isn't available, I would use a href to the current URL, and perhaps an anchor to the position of the link. The page is still be usable for the people without JavaScript those who have won't notice any difference.
As I have it to hand, here is some jQuery which might help:
var [functionName] = function() {
};
jQuery("[link id or other selector]").bind("click", [functionName]);
Ideally you should have a real URL as fallback for non-JavaScript users.
ReplyDeleteIf this doesn't make sense, use # as the href attribute. I don't like using the onclick attribute since it embeds JavaScript directly in the HTML. A better idea would be to use an external JS file and then add the event handler to that link. You can then prevent the default event so that the URL doesn't change to append the # after the user clicks it.
I choose use javascript:void(0), because use this could prevent right click to open the content menu.
ReplyDeleteYou can also write a hint in an anchor like this:
ReplyDelete<a href="javascript:void('open popup image')" onclick="return f()">...</a>
so the user will know what this link does.
What I understand from your words is that you want to create a link just to run JavaScript code.
ReplyDeleteThen you should consider that there are people who blocks JavaScript out there in their browsers.
So if you are really going to use that link only for running a JavaScript function then you should add it dynamically so it won't be even seen if the users didn't enable their JavaScript in the browser and you are using that link just to trigger a JavaScript function which makes no sense to use a link like that when JavaScript is disabled in the browser.
For that reason neither of them is good when JavaScript is disabled.
Aand if JavaScript is enabled and you only want to use that link to invoke a JavaScript function then
<a href="javascript:void(0)" onclick="myJsFunc();">Link</a>
is far better way than using
<a href="#" onclick="myJsFunc();">Link</a>
because href="#" is going to cause the page to do actions that are not needed.
Also, another reason why <a href="javascript:void(0)" onclick="myJsFunc();">Link</a> is better than <a href="#" onclick="myJsFunc();">Link</a> is that JavaScript is used as the default scripting language for most of the browsers. As an example Internet Explorer, uses an onclick attribute to define the type of scripting language that would be used. Unless another good scripting language pops up, JavaScript will be used by Internet Explorer as the default too, but if another scripting language used javascript:, it would let Internet Explorer to understand which scripting language is being used.
Considering this, I would prefer using and exercising on
<a href="javascript:void(0)" onclick="myJsFunc();">Link</a>
enough to make it a habit and to be more user friendly please add that kind of links within the JavaScript code:
$(document).ready(function(){
$(".blabla").append('<a href="javascript:void(0)" onclick="myJsFunc();">Link</a>')
});
I believe you are presenting a false dichotomy. These are not the only two options.
ReplyDeleteI agree with Mr. D4V360 who suggested that, even though you are using the anchor tag, you do not truly have an anchor here. All you have is a special section of a document that should behave slightly different. A tag is far more appropriate.
It's nice to have your site be accessible by users with JavaScript disabled, in which case the href points to a page that performs the same action as the JavaScript being executed. Otherwise I use "#" with a "return false;" to prevent the default action (scroll to top of the page) as others have mentioned.
ReplyDeleteGoogling for "javascript:void(0)" provides a lot of information on this topic. Some of them, like this one mention reasons to NOT use void(0).
I strongly prefer to keep my JavaScript out of my HTML markup as much as possible. If I'm using <a> as click event handlers then I'd recommend using <a class="trigger" href="#">Click me!</a>.
ReplyDelete$('.trigger').click(function (e) {
e.preventDefault();
// Do stuff...
});
It's very important to note that many developers out there believe that using anchor tags for click-event handlers isn't good. They'd prefer you to use a <span> or <div> with some CSS that adds cursor: pointer; to it. This is a matter if much debate.
Usually, you should always have a fall back link to make sure that clients with JavaScript disabled still has some functionality. This concept is called unobtrusive JavaScript. Example... Let's say you have the following search link:
ReplyDelete<a href="search.php" id="searchLink">Search</a>
You can always do the following:
var link = document.getElementById('searchLink');
link.onclick = function() {
try {
// Do Stuff Here
} finally {
return false;
}
};
That way, people with JavaScript disabled are directed to search.php while your viewers with JavaScript view your enhanced functionality.
There is one more important thing to remember here. Section 508 compliance.
ReplyDeleteBecause of it, I feel it's necessary to point out that you need the anchor tag for screen readers such as JAWS to be able to focus it through tabbing. So the solution "just use JavaScript and forget the anchor to begin with" is not an option for some of this. Firing the JavaScript inside the href is only necessary if you can't afford for the screen to jump back up to the top. You can use a settimeout for 0 seconds and have JavaScript fire to where you need focus but even the apage will jump to the top and then back.
Don't lose sight of the fact that your URL may be necessary -- onclick is fired before the reference is followed, so sometimes you will need to process something clientside before navigating off the page.
ReplyDelete