Why Is It Bad Practice to Use Links With the JavaScript: "Protocol"

Why is it bad practice to use links with the javascript: protocol?

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

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

javascript: is executed in the global context, not as a method of the element, which is usually want you want. In most cases you're doing something with or in relation to the element you acted on, better to execute it in that context.

Also, it's just much cleaner, though I wouldn't use in-line script at all. Check out any framework for handling these things in a much cleaner way. Example in jQuery:

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

is it bad practice to use href='javascript:func()' than onclick='func()' for anchors?

Neither.

Use this:

<a href="javascript-disabled-page" onclick="func(); return false;">blah</a>

That way if the user has JS disabled, they will be taken to javascript-disabled-page and the browsing experience isn't ruined.

javascript: protocol is bad, but what is the most accessible alternative?

There is a corresponding recommendation:

http://www.w3.org/TR/DOM-Level-3-Events/#click-synthesis

If the instance of the activation trigger is not an event of event
type click (that is, when it does not result from a user's activation
of a button or link using a mouse or equivalent pointing device), the
implementation MUST synthesize and dispatch an event of event type
click as one of the default actions of that activation trigger. The
value of the Event.target MUST be set to the event target (normally,
the currently focused element), and the event MUST simulate a left
click (i.e., the MouseEvent.button attribute value MUST be 0, and the
MouseEvent.buttons attribute value MUST be 1). Other context
information of such a simulated click event is implementation
dependent, but for historical purposes, the interface for the click
event MUST be the MouseEvent interface, regardless of the actual
device used to activate the element. Preventing the default action of
the activation trigger, such as with the Event.preventDefault(), MUST
stop the initiation of the activation behavior.

And an example:

When a user activates a hyperlink using a keyboard, such as by focusing the hyperlink element and pressing the 'Enter' or ' ' key, a click event would be dispatched as the default action of the respective keydown event.

Basicly, click event is a way to go.

It is wrong or a bad practice to use javascript:// as links to prevent action?

It is bad practice because a better mechanism exists and that is event.preventDefault().

Also, the javascript: pseudo protocol should only be used for bookmarklets.

Is it bad practice to embed JavaScript into the body of HTML?

It's perfectly valid.

You wouldn't want to put great big blocks of code mixed up in the markup there (better to use external scripts), but it can be useful to:

add extra binding information for progressive-enhancement (where that data is difficult to fit into a classname or other approach to hiding extended information in attributes); or
where it's necessary to kick off a scripted enhancement as quickly as possible (rather than waiting for window-load/document-ready). An example of this would be autofocus, which can irritate if fired too late.

You may be thinking of <style> elements, which aren't allowed in <body> (although most browsers allow it nonetheless).

Why use protocol-relative URLs at all?

As of December 2014, Paul Irish's blog on protocol-relative URLs says:

2014.12.17: Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.

Unless you have specific performance concerns (such as the slow mobile network mentioned in Zakjan's answer) you should use https:// to protect your users.

Anything wrong with asking URL without protocols?

In short, yes, there are reasons/rules to ask specifically for HTTPS or implement it on the back-end yourself.

In my personal experience, you can have security errors come up on the client side because the browser might detect it as being an evil twin link.

And https://www.paulirish.com/2010/the-protocol-relative-url/ says:

Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.

If you fix it on the back end to add the url protocol yourself though this is all moot, that would be the best solution. I would use front-end validation for only checking if it is input a valid way, then check on the back-end again, and determine in what form they did it, ie. https://google.com, www.google.com, google.com, etc.

Good luck!

When do I need to specify the JavaScript protocol?

The javascript: pseudo-protocol on event handlers will be only ignored, you don't need it, the JavaScript engine will interpret javascript: as a Label Statement.

A label simply provides an identifier to a statement, and lets you refer to it elsewhere in your program.

IMHO, this pseudo-protocol is only useful for bookmarklets...

Why Is It Bad Practice to Use Links With the JavaScript: "Protocol"