Hi,

while checking a script and reducing a lot of flaws in it with the
webjslint, the following message came up:

Problem at line 130 character 34: 'escape' is undefined.

var curCookie = name + "=" + escape(value) +

while I had checked the option "assume a browser" and from what I know
escape and unescape are native functions in at least a browser, that
message came anyway.

Does anyone have a hint to avoid that message (which comes up for
unescape as well)?

thanks in advance :-)

--
Michael

Don't use escape. Use  encodeURI or encodeURIComponent instead.

michael.gollmick wrote:
> Hi,
>
> while checking a script and reducing a lot of flaws in it with the
> webjslint, the following message came up:
>
> Problem at line 130 character 34: 'escape' is undefined.
>
> var curCookie = name + "=" + escape(value) +
>
> while I had checked the option "assume a browser" and from what I know
> escape and unescape are native functions in at least a browser, that
> message came anyway.
>
> Does anyone have a hint to avoid that message (which comes up for
> unescape as well)?
>
> thanks in advance :-)
>
> --
> Michael
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--- In jslint_com@yahoogroups.com, Douglas Crockford <douglas@...> wrote:
>
> Don't use escape. Use  encodeURI or encodeURIComponent instead.

But what if the server can't handle UTF-8 encoded characters? Many
legacy applications are stuck with escape/unescape.

   - Conrad

crlender wrote:
> --- In jslint_com@yahoogroups.com, Douglas Crockford <douglas@...> wrote:
>> Don't use escape. Use  encodeURI or encodeURIComponent instead.
>
> But what if the server can't handle UTF-8 encoded characters? Many
> legacy applications are stuck with escape/unescape.

/*global escape */

--- In jslint_com@yahoogroups.com, Douglas Crockford <douglas@...> wrote:
>
> crlender wrote:
> > --- In jslint_com@yahoogroups.com, Douglas Crockford <douglas@> wrote:
> >> Don't use escape. Use  encodeURI or encodeURIComponent instead.
> >
> > But what if the server can't handle UTF-8 encoded characters? Many
> > legacy applications are stuck with escape/unescape.
>
> /*global escape */
>
absolutely - that was my solution too ;-) I just thought every browser
implements that extension to the ECMA Script and thus expected it to
disappear with checking the "assume a browser" option. But I was
probably wrong.

--
Michael

The documentation suggests that this should work:

/*jslint newcap: true */
or
/*jslint newcap: false */

However, JSLint itself complains about this being a "Bad Option."


--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> I have added a new option:
>
>     [ ] Require Initial Caps for constructors (option.newcap)
>

--- In jslint_com@yahoogroups.com, "Chris" <Nielsen.Chris@...> wrote:
>
> The documentation suggests that this should work:
>
> /*jslint newcap: true */
> or
> /*jslint newcap: false */
>
> However, JSLint itself complains about this being a "Bad Option."

Thanks for the report.

Maybe I am a bit out of topic, but the subject is the foundation of
JSlint. :)

Reading "Top Down Operator Precedence" paper [1] and trying to use his
demonstration [2], it seems it is not defined the function
"Object.create", described in "Prototypal Inheritance" paper [3].

I was wondering if you could add the code in parse.js.

A very little example would help too:

var my_parse = make_parse();
var source = "var a = 1;";
var ast = my_parse(source); // ast contains the abstract syntax tree
JSON.stringify(ast);

stringify gives an internalError (too much recursion) using the
firebug console. What have been I missing?

Regards,
Alberto

[1] http://javascript.crockford.com/tdop/tdop.html
[2] http://javascript.crockford.com/tdop/index.html
[3] http://javascript.crockford.com/prototypal.html

When JSLint encounters a serious error, it stops.
Is it possible to program in a error handling statement that breaks out
of that block, outputs that lines x-y were not evaluated due to an
error on line x char y?

I hate having to use other lints due to the finicky and limited results
output by this lint.  The finicky nature of this lint is a double edged
sword.  I'm finding that I'm using The Javascript Lint to clean things
up before running code through this lint when my code is more or less
working.

--- In jslint_com@yahoogroups.com, "aceblchboy" <aceblchboy@...> wrote:
>
> When JSLint encounters a serious error, it stops.
> Is it possible to program in a error handling statement that breaks out
> of that block, outputs that lines x-y were not evaluated due to an
> error on line x char y?
>
> I hate having to use other lints due to the finicky and limited results
> output by this lint.  The finicky nature of this lint is a double edged
> sword.  I'm finding that I'm using The Javascript Lint to clean things
> up before running code through this lint when my code is more or less
> working.


Just fix your code. Hooking JSLint into your editor can be very effective.

Hi,

JSLint forbids the following form:

var a = var b = foo(); // Expected an identifier and instead saw 'var'.

Is this intentional? It can occasionally be useful where two variables
start at the same value and then diverge.

Dan.

Hi,

With 'assume browser' turned on, JSLint rejects the following:

if (n instanceof Document) { // 'Document' is undefined
     // ...
}


Shouldn't the DOM classes (Document, Element, ...) be defined when
assuming a browser, or is this intentional?

Thanks,
Dan.

--- In jslint_com@yahoogroups.com, "Daniel Cassidy" <mail@...> wrote:
> JSLint forbids the following form:
>
> var a = var b = foo(); // Expected an identifier and instead saw 'var'.
>
> Is this intentional?

Of course.

--- In jslint_com@yahoogroups.com, "Daniel Cassidy" <mail@...> wrote:
> Shouldn't the DOM classes (Document, Element, ...) be defined when
> assuming a browser, or is this intentional?

My understanding is that these are not universally implemented in all
browsers, and so represent a portability trap.

I believe the var declaration is not legal as the right side of a statement; it
would require 'var b' to return a value, which it does not. Try:
var a, b;
a = b = foo();

Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: "Douglas Crockford" <douglas@...>

Date: Tue, 16 Dec 2008 15:00:28
To: <jslint_com@yahoogroups.com>
Subject: [jslint] Re: var a = var b = foo();


--- In jslint_com@yahoogroups.com, "Daniel Cassidy" <mail@...> wrote:
> JSLint forbids the following form:
>
> var a = var b = foo(); // Expected an identifier and instead saw 'var'.
>
> Is this intentional?

Of course.




[Non-text portions of this message have been removed]

2008/12/16 Douglas Crockford <douglas@...>:
> --- In jslint_com@yahoogroups.com, "Daniel Cassidy" <mail@...> wrote:
>> JSLint forbids the following form:
>>
>> var a = var b = foo(); // Expected an identifier and instead saw 'var'.
>>
>> Is this intentional?
>
> Of course.

Uhh... sorry. It is of course a syntax error.

Chalk that one up to temporary insanity on my part. I was thinking of
another language where "var b" is an expression, and so returns a
value (as well as declaring a variable).

Dan.

> With 'assume browser' turned on, JSLint rejects the following:

> if (n instanceof Document) { // 'Document' is undefined
>     // ...
> }


> Shouldn't the DOM classes (Document, Element, ...) be defined when
> assuming a browser, or is this intentional?

Try this:

alert(document);
alert(Document);


Javascript is case sensitive!

Yes, JS is case sensitive; document is referring to a specific object that
exists in all browsers, while Document refers to the class that object should be
an instance of. IE doesn't support those standard DOM classes that the original
poster is looking for.

Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: kaichen67@...

Date: Wed, 17 Dec 2008 21:10:04
To: <jslint_com@yahoogroups.com>
Subject: Re: [jslint] DOM classes undefined



> With 'assume browser' turned on, JSLint rejects the following:

> if (n instanceof Document) { // 'Document' is undefined
>     // ...
> }


> Shouldn't the DOM classes (Document, Element, ...) be defined when
> assuming a browser, or is this intentional?

Try this:

alert(document);
alert(Document);


Javascript is case sensitive!






[Non-text portions of this message have been removed]

I made two changes to the way JSLint deals with HTML:

1. <!-- --> comments have been relaxed to allow the commenting out of
HTML content. JSLint will complain if a comment contains '<!' or '--'.

2. Restrictions have been added to the values of id, name, type, and
class attributes. They may not contain characters that could interfere
with query patterns. Use of query patterns has become important in
Ajax frameworks.

Please let me know if these changes introduce problems for you.

What about "let" keyword?

https://developer.mozilla.org/en/New_in_JavaScript_1.7

For instance,

for (let i = 0; i < 10; i = i + 1) {
   // loop stuff with local variable "i"
}

Happy Christmas,
Alberto Santini

--- In jslint_com@yahoogroups.com, "santini.alberto"
<albertosantini@...> wrote:
>
> What about "let" keyword?
>
> https://developer.mozilla.org/en/New_in_JavaScript_1.7
>
> For instance,
>
> for (let i = 0; i < 10; i = i + 1) {
>   // loop stuff with local variable "i"
> }

Of course not. let is not in the standard, and will not be in the next
edition. If you care about standards compliance and portability, you
will avoid it. There is no program that you can write with let that
cannot as easily be written with var.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
> will avoid it. There is no program that you can write with let that
> cannot as easily be written with var.

Thanks... I know that... but I saw an intensive use of let keyword in
the Mozilla extension Ubiquity. And I learn by example... :)

Regards,
Alberto

I guess we will have to fork jslint to have a -mozilla option ;)

On Tue, Dec 23, 2008 at 1:12 PM, santini.alberto
<albertosantini@...>wrote:

> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
> wrote:
> > will avoid it. There is no program that you can write with let that
> > cannot as easily be written with var.
>
> Thanks... I know that... but I saw an intensive use of let keyword in
> the Mozilla extension Ubiquity. And I learn by example... :)
>
> Regards,
> Alberto
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Thanks Anton,

(forwarding to the jslint group)

YSlow has an older version of JSLint, so I pasted your test code into
jslint.com and got a different error message, which doesn't look right
to me personally, but I will leave the group to provide a better
explanation.

Test:
--
var b;
var a = b = 123;

JSLint response:
--
Error:
Problem at line 2 character 9: Variable b was not declared correctly.
var a = b = 123;


Best,
Stoyan



-----Original Message-----
From: Anton [mailto:aggtaa@...]
Sent: Sunday, December 14, 2008 12:48 AM
To: yslow@...
Subject: JSLint error

Name: Anton

Email: aggtaa@...

Message:
Hello.

I'm not a jslint user group member nor want to become one just to
report a bug, so I desided to report it to you as you must be a
concerned party.

JSLint appears to be not accepting multiple asiignments in one
operator. It spawns host of errors and stops analysing code. This bug
appears in particular on jquery-1.2.6.js:
---
Missing ';' line 18, char 26:   ignore all
var jQuery = window.jQuery = window.$ = function( selector, context
)
Expected an identifier and instead saw '='. line 18, char 27:
   ignore all
var jQuery = window.jQuery = window.$ = function( selector, context
)
Stopping, unable to continue. (0% scanned) line 18, char 27:   ignore
all
var jQuery = window.jQuery = window.$ = function( selector, context
)
---

Piece of code to reproduce:
---
var b;
var a = b = 123;
---

--- In jslint_com@yahoogroups.com, "Stoyan Stefanov" <stoyan@...> wrote:
> YSlow has an older version of JSLint, so I pasted your test code into
> jslint.com and got a different error message, which doesn't look right
> to me personally, but I will leave the group to provide a better
> explanation.
>
> Test:
> --
> var b;
> var a = b = 123;
>
> JSLint response:
> --
> Error:
> Problem at line 2 character 9: Variable b was not declared correctly.
> var a = b = 123;

The var statement

     var a = b = 123;

is a common error, with people thinking they are declaring two local
variables but in reality declaring one local variable and one dreaded
global variable. In your example, this is not the case because b was
already declared, but it looks like a common error, and when your
programs look like errors, it becomes harder to see the real errors.

So whenever you use assignment as an expression, I recommend that you
wrap it in parens to demonstrate that you actually know what you are
doing.

     var a = (b = 123);

Hi,

I just checked the following small line of code with jslint:

     document.write('hello');

And I got this error : "document.write can be a form of eval."


I would be glad if someone could guide me to information about this error.


Thanks,

Haluk

--- In jslint_com@yahoogroups.com, "halukakin" <halukakin@...> wrote:
> I just checked the following small line of code with jslint:
>
>     document.write('hello');
>
> And I got this error : "document.write can be a form of eval."
>
> I would be glad if someone could guide me to information about this
error.

eval comes in several forms, and is usually to be avoided.
document.write is the worst of them.

If you wish to ignore this advice, check the Tolerate eval option.

Which ActiveX Object should I search for to cover for versions IE 6-8?

I was told IE switched their ActiveX Obkect in IE 7 from
"Microsoft.XMLHTTP" to something else but was never told what. Does
anyone know?

This function:

   function isValidBZ (val) {
       return /^(?:[1-9]\d*|0)$/.test(val);
   }

triggers the JSLint warning "Wrap the /regexp/ literal in parens
to disambiguate the slash operator". Could you clarify this? I
can't see any ambiguities in that line.

Thanks.


   - Conrad

--- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:

> This function:
>
>   function isValidBZ (val) {
>       return /^(?:[1-9]\d*|0)$/.test(val);
>   }
>
> triggers the JSLint warning "Wrap the /regexp/ literal in parens
> to disambiguate the slash operator". Could you clarify this? I
> can't see any ambiguities in that line.

This case is decidable, which is why JavaScript parsers are able to
work, but there are problems in the language because it can be
difficult to determine the meaning of / without doing a full parse.
That is why I recommend that you write

     return (/^(?:[1-9]\d*|0)$/).test(val);