Why does bad practice use links with javascript: "protocol"?

Question

In the 1990s, a fashion appeared to put Javascript code directly in the <a> href attributes, for example:

 <a href="javascript:alert('Hello world!')">Press me!</a> 

And suddenly I stopped to see this. All of them have been replaced with such things as:

 <a href="#" onclick="alert('Hello world!')">Press me!</a> 

For a link whose sole purpose is to run Javascript code and there is no real href goal, why is it recommended to use the onclick property instead of the href property?

Answer 1

The execution context is different, to see this, try these links:

 <a href="javascript:alert(this.tagName)">Press me!</a> <!-- result: undefined --> <a href="#" onclick="alert(this.tagName)">Press me!</a> <!-- result: A --> 

javascript: executed in a global context, and not as an element method that you usually need. In most cases, you are doing something with or in relation to the element on which you acted, and it is better to execute it in this context.

It is also much cleaner, although I would not use the built-in script at all. Browse through any framework for handling these things in a much cleaner way. Example in jQuery:

 $('a').click(function() { alert(this.tagName); }); 

Answer 2

In fact, both methods are considered obsolete. Instead, developers are encouraged to separate all JavaScript in an external JS file to separate logic and code from genuine markup.

• http://www.alistapart.com/articles/behavioralseparation
• http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

The reason for this is that it creates code that is easier to maintain and debug, and also contributes to web standards and accessibility. Think of it this way: look at your example, that if you had hundreds of links on a page and you needed to change alert behavior for some other function using JS external links, you only need to change the binding of one event in one JS file, as opposed to copying and pasting heaps of code over and over or performing searches and replacements.

Answer 3

A couple of reasons:

• Bad code practice:
  The HREF tag must point to a hyperlink link to another location. Using the same tag for a javascript function that doesn’t actually accept the user anywhere is a bad programming practice.

• SEO issues:
  I think web crawlers use the HREF tag to scan throughout the website and link all related parts. By inserting javascript, we violate this functionality.

• Accessibility Accessibility:
  I think some screen readers will not be able to execute javascript and may not know how to handle javascript while they are expecting hyperlinks. The user will wait for the link in the browser status bar when hovering the link, while they see a line like "javascript:", which may confuse them, etc.

• You are still in the 1990s:
  The basic advice is to keep your javascript in a separate file and not mix with the page’s HTML page, as was done in the 1990s.

NTN.

Answer 4

I open many links on new tabs - just for viewing javascript: void (). That way, you annoy me, as you do (because Google will see the same thing).

Another reason (also mentioned by others) is that different languages ​​should be divided into different documents. What for? Well,

• Mixed languages ​​are not supported by most IDEs and validators. Embedding CSS and JS in HTML pages (or anything else for that matter) greatly destroys the ability to statically validate an embedded language. Sometimes, the language of introduction. (The PHP document or ASP document is not valid HTML.) The syntax does not need errors or inconsistencies only at run time.
• Another reason is a cleaner separation of the kinds of things you need to specify: HTML for content, CSS for layout, JS usually for a larger layout and appearance. They do not display one to one: you usually want to apply content elements (hence CSS) and appearance (hence jQuery) across all categories. They can be changed at different times when content elements change (in fact, content is often generated on the fly) and by various people. Therefore, it makes sense to keep them in separate documents as well.

Answer 5

Short answer: Inline Javascript is bad for the reasons that inline CSS is bad.

Answer 6

Using the javascript: protocol javascript: affects accessibility and also damages how optimized your SEO page is.

Note that HTML means that Hypter Text is something ... Hyper Text stands for text with links and links in it, which uses the <a> anchor element.

When you use the javascript: 'protocol, you are using the binding element incorrectly. Since you are not using the <a> element correctly, things like Google Bot and the Jaws Screen reader will have problems understanding your page, because they don't really care about your JS, but they care about Hyper Text ML, taking in the hrefs anchor special note .

It also affects the usability of your page when a user who does not have JavaScript visits your page; You are violating the expected functionality and behavior of the links for these users. It will look like a link, but it will not act like a link because it uses the javascript protocol.

You might think, "But how many people have JavaScript disabled right now?" but I like the phrase of this idea as a whole: "How many potential customers do I want to turn off just because of the checkbox in my browser settings?"

It comes down to the fact that href is an attribute of HTML, and as such it relates to your site information, and not to its behavior. JavaScript defines behavior, but you never want it to interfere with data / information. An example of this idea would be an external JavaScript file; not using onclick as an attribute, but instead as an event handler in your JavaScript file.

Answer 7

The worst problem is probably that it violates the expected functionality.
For example, as others have pointed out, open in a new window / tab = dead link = annoyed / confused users.

I always try to use onclick instead, and add something to the URL hash of the page to indicate the desired function to run and add a check to pageload to check the hash and call the function.

This way you get the same behavior for clicks, a new tab / window, and even bookmarks / sent links, and everything doesn't get awkward if JS is disabled.

In other words, something like this ( very simplified ):

For reference:

 onclick = "doStuff()" href = "#dostuff" 

For page:

 onLoad = if(hash="dostuff") doStuff(); 

Answer 8

In addition, if we are talking about obsolescence and semantics, it is probably worth noting that " </a> " does not mean "clickable" - it means "linking" and implies a link to another page. Therefore, it would be advisable to use this tag to switch to another "view" in your application, but not to perform the calculation. The fact that you do not have a URL in your href attribute should be a sign that you should not use the anchor tag.

You can, in turn, assign a click event action to almost any html element - maybe <h1> , <img> or <p> could be more appropriate? Anyway, as other people have noted, add another attribute (possibly "id") that javascript can use as a "hook" (document.getElementById) to get to the element and assign onclick. This way you can separate presentation of content (HTML) and interactivity (JavaScript). And the world will not end.

Answer 9

I think this is due to what the user sees in the status bar. Typically, applications should be built for fault tolerance if javascript is not enabled, however this is not always the case.

When all the spam that happens, people get smarter, and when the email looks “phishy”, more and more people look at the status bar to see where exactly their link will actually be.

Remember to add 'return false;' to the end of your link so that the page does not go to the top of the user (unless this behavior is required).

Answer 10

Usually I have a landing page called "EnableJavascript.htm" that has a big message saying: "Javascript must be enabled for this feature to work." And then I set my anchor tags like this ...

 <a href="EnableJavascript.htm" onclick="funcName(); return false;"> 

Thus, the anchor has a legitimate destination, which will be replaced, if possible, by your Javascript functionality. It will gracefully decline. Although, at present, I usually create websites with full functionality before I decide to sprinkle some Javascript into the mix (which together eliminates the need for anchors like this).

Using the onclick attribute directly in markup is a whole different topic, but I would recommend an unobtrusive approach to the library, like jQuery.