In JavaScript, everything is 'truthy' or 'falsy', and for numbers 0
means false
, everything else true
. So you could write:
if ($(selector).length)
You don't need that >0
part.
I use javascript:void(0)
.
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
.
OR
Use href="javascript:void(0)"
The second is clearly much easier to communicate.
Best Answer
The error
When code is parsed by the JavaScript interpreter, it gets broken into pieces called "tokens". When a token cannot be classified into one of the four basic token types, it gets labelled "ILLEGAL" on most implementations, and this error is thrown.
The same error is raised if, for example, you try to run a js file with a rogue
@
character, a misplaced curly brace, bracket, "smart quotes", single quotes not enclosed properly (e.g.this.run('dev1)
) and so on.But I can't see anything illegal!
There is an invisible character in the code, right after the semicolon. It's the Unicode
U+200B
Zero-width space character (a.k.a.ZWSP
, HTML entity​
). That character is known to cause theUnexpected token ILLEGAL
JavaScript syntax error.And where did it come from?
I can't tell for sure, but my bet is on jsfiddle. If you paste code from there, it's very likely to include one or more
U+200B
characters. It seems the tool uses that character to control word-wrapping on long strings.It's also been reported that code pasted from the Chrome developer tools may include that character, but I was unable to reproduce that with the current version (22.0.1229.79 on OSX).
How can I spot it?
The character is invisible, do how do we know it's there? You can ask your editor to show invisible characters. Most text editors have this feature. Vim, for example, displays them by default, and the
ZWSP
shows as<u200b>
. You can also debug it online: jsbin displays the character as a red dot on its code panes (but seems to remove it after saving and reloading the page). CodePen.io also displays it as a dot, and keeps it even after saving.Related problems
That character is not something bad, it can actually be quite useful. This example on Wikipedia demonstrates how it can be used to control where a long string should be wrapped to the next line. However, if you are unaware of the character's presence on your markup, it may become a problem. If you have it inside of a string (e.g., the
nodeValue
of a DOM element that has no visible content), you might expect such string to be empty, when in fact it's not (even after applyingString.trim
).ZWSP
can also cause extra whitespace to be displayed on an HTML page, for example when it's found between two<div>
elements (as seen on this question). This case is not even reproducible on jsfiddle, since the character is ignored there.Another potential problem: if the web page's encoding is not recognized as UTF-8, the character may actually be displayed (as
​
in latin1, for example).If
ZWSP
is present on CSS code (inline code, or an external stylesheet), styles can also not be parsed properly, so some styles don't get applied (as seen on this question).The ECMAScript Specification
I couldn't find any mention to that specific character on the ECMAScript Specification (versions 3 and 5.1). The current version mentions similar characters (
U+200C
andU+200D
) on Section 7.1, which says they should be treated asIdentifierPart
s when "outside of comments, string literals, and regular expression literals". Those characters may, for example, be part of a variable name (andvar x\u200c;
indeed works).Section 7.2 lists the valid White space characters (such as tab, space, no-break space, etc.), and vaguely mentions that any other Unicode “space separator” (category “Zs”) should be treated as white space. I'm probably not the best person to discuss the specs in this regard, but it seems to me that
U+200B
should be considered white space according to that, when in fact the implementations (at least Chrome and Firefox) appear to treat them as an unexpected token (or part of one), causing the syntax error.