I corrected an error in JSLint that created a scope around labeled
statements.

function a() {
foo:
     for (var i = 0; false;) {
     }
     return i;
}

As a result, it used to find an error on the return statement because
i was out of scope.

JSLint now rejects a string that starts with 'javascript:'. It
previously rejected a string that contained 'javascript:'.

Thanks to Timo.

--- In jslint_com@yahoogroups.com, "Re Miya" <remiya_ws@...> wrote:
> This is the first time I heard that escape and unescape do not do URL
> encoding correctly, and are not in the official standard. Where can I
> find more information about this issue? Will this issue be resolved in
> the next JavaScript releases?
>
> What solution would you propose for escape and unescape?

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/j\
s56jsmthescape.asp

The ECMAScript standard reserves the following words:

abstract boolean byte char double final float implements int interface
long native package private protected public short static synchronized
throws transient volatile

None of those words are actually reserved by the 4 current browsers.
They will not be reserved in the next edition of the ECMAScript
standard. So I want to unreserved them in JSLint.

Will this cause a problem for other implentations of ECMAScript? In
particular, could that be a problem for Rhino?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> escape & unescape do not do url encoding correctly and they are not in
> the official standard. JSLint no longer accepts them. If you want
> JSLint to pass crappy legacy code containing them, insert
>
>     /*global escape, unescape */
>
> in your program.

Hello Douglas,

This is the first time I heard that escape and unescape do not do URL
encoding correctly, and are not in the official standard. Where can I
find more information about this issue? Will this issue be resolved in
the next JavaScript releases?

What solution would you propose for escape and unescape?

Best regards.

escape & unescape do not do url encoding correctly and they are not in
the official standard. JSLint no longer accepts them. If you want
JSLint to pass crappy legacy code containing them, insert

     /*global escape, unescape */

in your program.

I added arguments to the set of excluded members. The set now contains

apply arguments call callee caller constructor
eval prototype unwatch valueOf watch

Hi,
I have created an MSBuild task that can be used to automate the
process of running the JSLint tool on Javascript files. You can read
about it on my blog at
http://www.sedodream.com/PermaLink,guid,8e4c1e41-393b-402b-8251-10f3f59a54e2.asp\
x.
If you are interested in it please take a look & let me know what you
think.

It also can be used to integrate in to the Visual Studio build process.

Thanks,
Sayed Ibrahim Hashimi

--- In jslint_com@yahoogroups.com, Cory Bennett <coryb@...> wrote:
> I got this error from jslint:
> Unsafe character.
>         fn("FAILEDâ€"" + message);
>
> The 'â€"' is char 226 or 0xe2.  It is not ascii, but I was wondering
why it
> mattered since it is in a quoted string.

There are characters that are handled inconsistently in the various
implementations, and so must be escaped when placed in strings, and
must never be used outside of strings:

\u0000-\u001f
\u007f-\u009f
\u00ad
\u0600-\u0604
\u070f
\u17b4
\u17b5
\u200c-\u200f
\u2028-\u202f
\u2060-\u206f
\ufeff
\ufff0-\uffff

Hello,

I got this error from jslint:
Unsafe character.
         fn("FAILED—" + message);

The '—' is char 226 or 0xe2.  It is not ascii, but I was wondering why it
mattered since it is in a quoted string.  I didnt not see any reference
to "Unsafe character" on the website.

Thanks
-Cory

--- In jslint_com@yahoogroups.com, "hass0002" <sayed.hashimi@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@>
> wrote:
> >
> > I relaxed ADsafe to allow limited access to the standard globals.
> >
> Do you think it would be a good idea to include a version comment in
> the JSLint source file? I'm working on something and I think it would
> be good to say what version of the JSLint it is using.

I use dates.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> I relaxed ADsafe to allow limited access to the standard globals.
>
Do you think it would be a good idea to include a version comment in
the JSLint source file? I'm working on something and I think it would
be good to say what version of the JSLint it is using.

Sayed Ibrahim Hashimi

I relaxed ADsafe to allow limited access to the standard globals.

I have added a glovar option. When glovar: true, then var cannot be
used to declare global variables.

Fiann O'Hagan convinced me that many programmers have a reasonable
expectation that top level var scopes to the compilation unit, like
C's static. It doesn't, and unmet expectations can induce bugs.
Further, var at the top level in implemented inconsistently, so

     var foo = this.foo || {};

does not do what you would expect on IE7.

JSLint will give the best results if you use the /*global*/ comment to
declare your globals.

     /*global foo*/

I added a warning to the web page edition at http://www.JSLint.com/:

     WARNING: JSLint will hurt your feelings.

I relaxed the ADsafe restriction on the [ ] operator slightly. It will
now accept subscript values that are number literals or string
literals that are not legal identifiers.

When confronted with a number literal like

     .0725

JSLint no longer reports

     Don't use extra leading zeros '0725'.

but it does report

     A leading decimal point can be confused with a dot: '.0725'.

--- In jslint_com@yahoogroups.com, "Chris" <Nielsen.Chris@...> wrote:
>
> When "Assume a Browser" is checked, why does the following code cause
> a problem?
>
> var o = new Option();
>
> Is there some browser that does not support the Option constructor?

That's a blast from the past.

JSLint now accepts it.

Howdy,

When "Assume a Browser" is checked, why does the following code cause
a problem?

var o = new Option();

Is there some browser that does not support the Option constructor?

- Chris

JSLint now recognizes Konfabulator's FormFiled constructor.

JSLint now prohibits assignment to the arguments pseudoarray.

The problem is that arguments is not a snapshot of the arguments that
are bound to the parameters. It remains linked, so changing an
elements of the arguments array changes a parameter.

--- Douglas Crockford wrote:
> This isn't Perl. JavaScript has a dangerous semicolon
> insertion mechanism. More rigor is demanded.

It certainly isn't Perl.  I'd argue it's much easier to write bad code
in Perl than JavaScript, but at least it doesn't insert semicolons for
you.  You've made that point many times.

Do any browsers actually insert a semicolon after an unbrace carriage
return?  I don't think I'm being unsafe with breaking the unbrace and
else statements with a carriage return.  Doing so has the advantage
that the "else" is lined up with the "if" statement, makes the code
more readable, and the blocks more defined.

If unbrace-return-else is actually dangerous, about which I'd like you
to convince me, perhaps we can change jslint to catch it.  If it's not
dangerous, there's no need to change anything.

This isn't Perl. JavaScript has a dangerous semicolon insertion mechanism. More
rigor is demanded.

Jacob Davenport wrote:
> In the world of Perl, we have this great book called Perl Best
> Practices, and there Conway argues that "else" should be written like
> this:
>
> if (ping == pong) {
>   dostuff();
> }
> else {
>   otherstuff();
> }
>
> So, I do the same in JavaScript, avoiding putting else on the same
> line as the unbrace.  jslint doesn't seem to mind this formatting when
> checking for white space.
>
> Views?
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

In the world of Perl, we have this great book called Perl Best
Practices, and there Conway argues that "else" should be written like
this:

if (ping == pong) {
   dostuff();
}
else {
   otherstuff();
}

So, I do the same in JavaScript, avoiding putting else on the same
line as the unbrace.  jslint doesn't seem to mind this formatting when
checking for white space.

Views?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> I have been convinced that . in Regular Expression literals is
> dangerous because it usually does not precisely match what was
> intended. That can lead to reliability and even secure problems.
>
> JSLint now has a 'regexp' option to reject /./.
>
I think this is a good option. I'm not sure if I will use it (at least
not at first) but this has me thinking more about my regular
expressions and using "." haphazardly.

I have been convinced that . in Regular Expression literals is
dangerous because it usually does not precisely match what was
intended. That can lead to reliability and even secure problems.

JSLint now has a 'regexp' option to reject /./.

JSLint now allows the letters in the tag, g i m, to appear in any
order. I had been expecting they would always be in alphabetical order.

An option has been added to support Windows Sidebar. It is the same as
the browser option, except that it also predefines System.

JSLint also replaces tabs with 4 spaces.

I can't recommend use of eval. Instead, try http://www.JSON.org/json2.js

Here at the US Courts we use YUI for our electronic case management
system, and recently use JLint to clean up our JavaScript code.

Although I personally prefer spaces for indentation over tabs, all the
other programmers here prefer tabs, so I changed my copy of the JLint
code to first change tabs to four spaces before processing.  A better
change would be to have an option for spaces versus tabs.

Our software is called "CMECF".  YUI has the YAHOO object, and I
created the CMECF object, so I added the option to "Assume CMECF object."

I tolerate eval by default because I eval JSON objects.  But if others
have found that parseJSON is sufficiently fast, I might change.  Views?

Douglas, thank you for a very helpful tool.

Added a more descriptive error message for if, do, for, and while
statements.