--- In jslint_com@yahoogroups.com, "santini.alberto" <albertosantini@...> wrote:
>
>
> It seems there is a difference if I use, for instance, FireFox (3.6.3) on
Windows XP: the web version catches correctly the two errors.
>
> In my first post I used Firefox 3.6.3 on Ubuntu 10.04.
>
> Locally on Windows or Linux, using the rhino approach, I get "only" the error
"Missing "use strict" statement.".
>
> The options are the same: good parts enabled.
>
> Any idea or suggestion?


It would seem that there is a bug in Rhino.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> It would seem that there is a bug in Rhino.
>

On Windows I used "cscript" executable and the output is equals to rhino one.

Same bug? Possible but with low probability.

Regards,
Alberto

Apologies if this has already been covered at an earlier date, I recently
came across this as an example of good coding practice:

// Don't
if (this.getBehavior("Modal")) {

     node.lastChild.style[property] = this._position[property] +

         (type(this._position[property]) === "number" ? "px" : "");
} else {

     node.style[property] = this._position[property] +

         (type(this._position[property]) === "number" ? "px" : "");
}
// Do
(this.getBehavior("Modal") ? node.lastChild : node).style[property] =
this._position[property] +

     (type(this._position[property]) === "number" ? "px" : "");


the second example advocates using the shorthand if statement repeatedly to
reduce the verbosity of the primary example.
I find the shorthand example terse, cryptic and hence difficult to read, but
I don't know if this is just a personal preference and if I'm missing
something that makes it better.
If I were writing this code I would probably introduce another variable and
write it half and half like this:

var nodeStyle =  node.style[property];
if(this.getBehavior("Modal")) {
  nodeStyle = node.lastChild.style[property];
}
nodeStyle = this._position[property] + (type(this._position[property]) ===
"number" ? "px" : "");

I was wondering what people's reactions/critiques/views were, is there one
dominant way or is it just preference?
If there is one way that is superior should it be a JSLint option?

Cheers

Simon

--
"We are the music makers, And we are the dreamers of dreams"


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

On Wed, May 19, 2010 at 9:43 AM, Simon Kenyon Shepard <
simon.shepard@...> wrote:

>
>
> Apologies if this has already been covered at an earlier date, I recently
> came across this as an example of good coding practice:
>
> // Don't
> if (this.getBehavior("Modal")) {
>
> node.lastChild.style[property] = this._position[property] +
>
> (type(this._position[property]) === "number" ? "px" : "");
> } else {
>
> node.style[property] = this._position[property] +
>
> (type(this._position[property]) === "number" ? "px" : "");
> }
> // Do
> (this.getBehavior("Modal") ? node.lastChild : node).style[property] =
> this._position[property] +
>
> (type(this._position[property]) === "number" ? "px" : "");
>
> the second example advocates using the shorthand if statement repeatedly to
> reduce the verbosity of the primary example.
> I find the shorthand example terse, cryptic and hence difficult to read,
> but
> I don't know if this is just a personal preference and if I'm missing
> something that makes it better.
> If I were writing this code I would probably introduce another variable and
> write it half and half like this:
>
> var nodeStyle = node.style[property];
> if(this.getBehavior("Modal")) {
> nodeStyle = node.lastChild.style[property];
> }
> nodeStyle = this._position[property] + (type(this._position[property]) ===
> "number" ? "px" : "");
>
> I was wondering what people's reactions/critiques/views were, is there one
> dominant way or is it just preference?
> If there is one way that is superior should it be a JSLint option?
>
I would do it like this:

units = type(this._position[property]) === "number" ? "px" : "";

nodeStyle = this.getBehavior("Modal") ?
   node.lastChild.style[property] :
   this._position[property] + units;

--
R. Mark Volkmann
Object Computing, Inc.


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

Thanks to Douglas, et al, for JSLINT.

I use it on Windows, with cscript.exe, in two ways:

  - from the command line and in build scripts (makefiles).
  - and within emacs as I edit .js files.


I've found it helpful to be able to specify a filename to jslint.js as an
argument, rather than sending the content of the source file into jslint.js via
STDIN.   The real advantage here is that an error message from jslint can
specifically identify the name of the .js file that contains the error.  It's
very helpful in make sessions; makes it easy to grep, and so on.

Instead of

      cscript.exe   jslint-for-wsh.js  < Module.js

I can now *also* use

    cscript.exe   jslint-for-wsh.js  Module.js

The change I made allows jslint to continue to use STDIN, if no argument is
specified.

Since I was changing the format of the jslint error message to include the
filename, I went one step further to make error messages similar to messages
from a {C, Java} compiler.  Instead of

     Lint at line 16 character 9: The body of a for in should be wrapped in an if
statement to filter unwanted properties from the prototype.

I now get:

     Module.js(16,9) JSLINT: The body of a for in .....

Using this error message format is really nice in emacs, which has a facility to
jump to the location of the next error in a particular file, given a list of
error messages.  Run make, then with one keystroke I have the cursor on the
location of the jslint error.  Very convenient.

It also makes it easy to integrate into flymake, if you're familiar with that. 
Flymake is a minor-mode in emacs that dynamically checks the file being edited
for syntax problems, and highlights them as you type.  It's a general feature
and is intended for use with any language. And syntax checking is JSLINT's
raison d'etre, so, it's a nice combination.  In action, using flymake with
JSLINT in emacs looks like this:

     http://i47.tinypic.com/2mk1eh.jpg

The change I made to jslint.js is relatively small, and it's confined to the
bottom of the jslint-for-wsh module available at http://www.jslint.com/wsh.   It
checks the WScript.Arguments array, and if an arg is present, the modified
jslint-for-wsh assumes.js the arg is the name of a file and tries to read the
named file.  If no arg is present, it does the same as before: read from STDIN.

I uploaded the modified file to the files list for the jslint_com group, so
anyone can have a look:

http://tech.groups.yahoo.com/group/jslint_com/files


-------

Questions for the group, or Douglas -

   1. regarding the change to allow reading from a file - does this look like a
general interest change?  I was surprised when searching the group archives to
find a message from a year ago on the converse situation in rhino - allowing
jslint to read from stdin.  ?? I'm a bit puzzled because I thought jslint read
*only* from stdin.  I must be missing something here.

   2. regarding the change to the error message format, is this friendly?  I'm
not familiar with the history behind the message format, if there are specific
reasons the messages are formatted the way they are.  In particular I'm not sure
if the jslint message format is designed to mirror popular message formats from
lint tools for other languages.

   It occurs to me that the proposed change in message format would make sense,
if in the future JSLINT expands to formalize and internationalize the warnings. 
Instead of just a string, the error or warning would be denoted by a unique
error code for each problem, as well as an internationalizable message.  Just
like a C compiler.

eg.

   JSL0019: The body of a for in should be wrapped in an if statement

----

I'm new here, so if anyone can answer or guide me, I'd appreciate it.
And if I'm violating group protocol in some way, my apologies.

-Dino Chiesa

I'm new here (but a old hand with JSLint -which I consider an excellent
teaching aid for Javascript; and a must if you want your code to run on
Internet Explorer)

In regards to Dino's suggestion for standard errors, I concur - but it
might help if the error also contained a succinct example of why it's
bad and how to avoid it. Perhaps a link to a separate area of the
website with each one documented. In his example:

JSL0019: The body of a for in should be wrapped in an if statement

I had just had this a few days hence when using a FOR IN to iterate over
an array: a bad thing to do, but the code evolved that way. Thanks to
JSLint it's now history and (also thanks to JSLint) I now program all my
JS code as a single global object under the current namespace  so I
don't pollute the place with my smeg ups.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
>
> It would seem that there is a bug in Rhino.
>

I jslinted the snippet with V8 [1]: it reports only "use strict" error.

No idea because it doesn't report also "unused variable" error.

Regards,
Alberto

[1] http://groups.google.com/group/nodejs/t/aa30e1b6f4f6314f

nice refactor



________________________________
From: Mark Volkmann <r.mark.volkmann@...>
To: jslint_com@yahoogroups.com
Sent: Wed, May 19, 2010 10:53:58 AM
Subject: Re: [jslint] shorthand if statements


On Wed, May 19, 2010 at 9:43 AM, Simon Kenyon Shepard <
simon.shepard@...> wrote:

>
>
> Apologies if this has already been covered at an earlier date, I recently
> came across this as an example of good coding practice:
>
> // Don't
> if (this.getBehavior("Modal")) {
>
> node.lastChild.style[property] = this._position[property] +
>
> (type(this._position[property]) === "number" ? "px" : "");
> } else {
>
> node.style[property] = this._position[property] +
>
> (type(this._position[property]) === "number" ? "px" : "");
> }
> // Do
> (this.getBehavior("Modal") ? node.lastChild : node).style[property] =
> this._position[property] +
>
> (type(this._position[property]) === "number" ? "px" : "");
>
> the second example advocates using the shorthand if statement repeatedly to
> reduce the verbosity of the primary example.
> I find the shorthand example terse, cryptic and hence difficult to read,
> but
> I don't know if this is just a personal preference and if I'm missing
> something that makes it better.
> If I were writing this code I would probably introduce another variable and
> write it half and half like this:
>
> var nodeStyle = node.style[property];
> if(this.getBehavior("Modal")) {
> nodeStyle = node.lastChild.style[property];
> }
> nodeStyle = this._position[property] + (type(this._position[property]) ===
> "number" ? "px" : "");
>
> I was wondering what people's reactions/critiques/views were, is there one
> dominant way or is it just preference?
> If there is one way that is superior should it be a JSLint option?
>
I would do it like this:

units = type(this._position[property]) === "number" ? "px" : "";

nodeStyle = this.getBehavior("Modal") ?
node.lastChild.style[property] :
this._position[property] + units;

--
R. Mark Volkmann
Object Computing, Inc.

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







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

The following generates the error "'e' is already defined.":
function f() {    try { } catch (e) { }    try { } catch (e) { }}
The identifier "e" is bound to the lexical environment of each catch
block, so it is not "already defined" within the scope of the function,
which is what the error seemingly refers to.
A warning for this case makes far more sense:
function f() {    var e = 1;    try { } catch (e) { }    try { } catch
(e) { }}
And JSLint does correctly report two errors. To those unfamiliar with
the language, it would be unclear what "e" refers to at various points
in f. I wholeheartedly endorse a JSLint error in this case!
Likewise, JSLint very correctly reports an error here, where "e" is not
defined outside of the catch block:
function f() {    try { } catch (e) { }    f(e);}
Now, obviously, one can write this instead:
function f() {    try { } catch (e1) { }    try { } catch (e2) { }}
... but I'm not convinced that this improves readability; I think it
impairs it by adding unnecessary clutter. Even using the same identifier
name in both catch clauses, the syntax of the program makes it explicit
that inside the second catch block, the identifier "e" can only be
referring to the value thrown by the second try block.
This is minor in the grand scheme of things, and I happily defer to our
benevolent dictator.



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

(1) apologies for the formatting - the Yahoo! Groups interface helpfully
offered a rich text editor, then apparently discarded the results both for
email and for the web interface to the group (
http://tech.groups.yahoo.com/group/jslint_com/message/1327)

(2) Re-reading my post, the last line could be taken as sarcasm, snark,
objection to a process, or disrespectful to those living
under oppressive regimes. None of those were intended - I'm truly happy with
Crockford's creation, maintenance, ownership of and vision for jslint.

On Fri, May 28, 2010 at 10:48 AM, Joshua <josh@...> wrote:

> The following generates the error "'e' is already defined.":
> function f() {    try { } catch (e) { }    try { } catch (e) { }}
> The identifier "e" is bound to the lexical environment of each catch
> block, so it is not "already defined" within the scope of the function,
> which is what the error seemingly refers to.
> A warning for this case makes far more sense:
> function f() {    var e = 1;    try { } catch (e) { }    try { } catch
> (e) { }}
> And JSLint does correctly report two errors. To those unfamiliar with
> the language, it would be unclear what "e" refers to at various points
> in f. I wholeheartedly endorse a JSLint error in this case!
> Likewise, JSLint very correctly reports an error here, where "e" is not
> defined outside of the catch block:
> function f() {    try { } catch (e) { }    f(e);}
> Now, obviously, one can write this instead:
> function f() {    try { } catch (e1) { }    try { } catch (e2) { }}
> ... but I'm not convinced that this improves readability; I think it
> impairs it by adding unnecessary clutter. Even using the same identifier
> name in both catch clauses, the syntax of the program makes it explicit
> that inside the second catch block, the identifier "e" can only be
> referring to the value thrown by the second try block.
> This is minor in the grand scheme of things, and I happily defer to our
> benevolent dictator.
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


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

It does not happen only in catch blocks.
JSLINT will flag the 2nd e in this code as well:

     if (condition1) {
         var e = new Error("This is unacceptable!");
         e.source = "Whatever";
         throw e;
     }

     if (condition2){
         var e = new Error("Some other problem occurred");
         throw e;
     }






From: Joshua
Sent: Friday, May 28, 2010 1:48 PM
To: jslint_com@yahoogroups.com
Subject: [jslint] Catch block identifier reuse flagged as error



The following generates the error "'e' is already defined.":
function f() { try { } catch (e) { } try { } catch (e) { }}
The identifier "e" is bound to the lexical environment of each catch
block, so it is not "already defined" within the scope of the function,
which is what the error seemingly refers to.
A warning for this case makes far more sense:
function f() { var e = 1; try { } catch (e) { } try { } catch
(e) { }}
And JSLint does correctly report two errors. To those unfamiliar with
the language, it would be unclear what "e" refers to at various points
in f. I wholeheartedly endorse a JSLint error in this case!
Likewise, JSLint very correctly reports an error here, where "e" is not
defined outside of the catch block:
function f() { try { } catch (e) { } f(e);}
Now, obviously, one can write this instead:
function f() { try { } catch (e1) { } try { } catch (e2) { }}
... but I'm not convinced that this improves readability; I think it
impairs it by adding unnecessary clutter. Even using the same identifier
name in both catch clauses, the syntax of the program makes it explicit
that inside the second catch block, the identifier "e" can only be
referring to the value thrown by the second try block.
This is minor in the grand scheme of things, and I happily defer to our
benevolent dictator.

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





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

http://www.jslint.com/lint.html#scope

That said, I'm unclear about try-catch blocks because we're not declaring
"var e"; e is an implicit variable just like function arguments. I would
certainly love to be able to re-use the same variable name, just as we can
do otherwise.

function foo(x) {
// x is already "declared"
alert(x);
// re-use x, no problem
x = 5;
// similarly, e is already "declared"
try { throw "oops"; } catch (e) { }
// so we should be able to re-use e as well, no?
try { throw "again"; } catch (e) { }
// but instead, JSLint returns an error for re-using e.
}

Aseem

On Fri, May 28, 2010 at 11:09 AM, D Chiesa <dpchiesa@...> wrote:

>
>
> It does not happen only in catch blocks.
> JSLINT will flag the 2nd e in this code as well:
>
> if (condition1) {
> var e = new Error("This is unacceptable!");
> e.source = "Whatever";
> throw e;
> }
>
> if (condition2){
> var e = new Error("Some other problem occurred");
> throw e;
> }
>
> From: Joshua
> Sent: Friday, May 28, 2010 1:48 PM
> To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
> Subject: [jslint] Catch block identifier reuse flagged as error
>
> The following generates the error "'e' is already defined.":
> function f() { try { } catch (e) { } try { } catch (e) { }}
> The identifier "e" is bound to the lexical environment of each catch
> block, so it is not "already defined" within the scope of the function,
> which is what the error seemingly refers to.
> A warning for this case makes far more sense:
> function f() { var e = 1; try { } catch (e) { } try { } catch
> (e) { }}
> And JSLint does correctly report two errors. To those unfamiliar with
> the language, it would be unclear what "e" refers to at various points
> in f. I wholeheartedly endorse a JSLint error in this case!
> Likewise, JSLint very correctly reports an error here, where "e" is not
> defined outside of the catch block:
> function f() { try { } catch (e) { } f(e);}
> Now, obviously, one can write this instead:
> function f() { try { } catch (e1) { } try { } catch (e2) { }}
> ... but I'm not convinced that this improves readability; I think it
> impairs it by adding unnecessary clutter. Even using the same identifier
> name in both catch clauses, the syntax of the program makes it explicit
> that inside the second catch block, the identifier "e" can only be
> referring to the value thrown by the second try block.
> This is minor in the grand scheme of things, and I happily defer to our
> benevolent dictator.
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>


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

Thank you, I've been enlightened.

--------------------------------------------------
From: "Aseem Kishore" <aseem.kishore@...>
Sent: Friday, May 28, 2010 2:15 PM
To: <jslint_com@yahoogroups.com>
Subject: Re: [jslint] Catch block identifier reuse flagged as error

> http://www.jslint.com/lint.html#scope
>
> That said, I'm unclear about try-catch blocks because we're not declaring
> "var e"; e is an implicit variable just like function arguments. I would
> certainly love to be able to re-use the same variable name, just as we can
> do otherwise.
>
> function foo(x) {
> // x is already "declared"
> alert(x);
> // re-use x, no problem
> x = 5;
> // similarly, e is already "declared"
> try { throw "oops"; } catch (e) { }
> // so we should be able to re-use e as well, no?
> try { throw "again"; } catch (e) { }
> // but instead, JSLint returns an error for re-using e.
> }
>
> Aseem
>
> On Fri, May 28, 2010 at 11:09 AM, D Chiesa <dpchiesa@...> wrote:
>
>>
>>
>> It does not happen only in catch blocks.
>> JSLINT will flag the 2nd e in this code as well:
>>
>> if (condition1) {
>> var e = new Error("This is unacceptable!");
>> e.source = "Whatever";
>> throw e;
>> }
>>
>> if (condition2){
>> var e = new Error("Some other problem occurred");
>> throw e;
>> }
>>
>> From: Joshua
>> Sent: Friday, May 28, 2010 1:48 PM
>> To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
>> Subject: [jslint] Catch block identifier reuse flagged as error
>>
>> The following generates the error "'e' is already defined.":
>> function f() { try { } catch (e) { } try { } catch (e) { }}
>> The identifier "e" is bound to the lexical environment of each catch
>> block, so it is not "already defined" within the scope of the function,
>> which is what the error seemingly refers to.
>> A warning for this case makes far more sense:
>> function f() { var e = 1; try { } catch (e) { } try { } catch
>> (e) { }}
>> And JSLint does correctly report two errors. To those unfamiliar with
>> the language, it would be unclear what "e" refers to at various points
>> in f. I wholeheartedly endorse a JSLint error in this case!
>> Likewise, JSLint very correctly reports an error here, where "e" is not
>> defined outside of the catch block:
>> function f() { try { } catch (e) { } f(e);}
>> Now, obviously, one can write this instead:
>> function f() { try { } catch (e1) { } try { } catch (e2) { }}
>> ... but I'm not convinced that this improves readability; I think it
>> impairs it by adding unnecessary clutter. Even using the same identifier
>> name in both catch clauses, the syntax of the program makes it explicit
>> that inside the second catch block, the identifier "e" can only be
>> referring to the value thrown by the second try block.
>> This is minor in the grand scheme of things, and I happily defer to our
>> benevolent dictator.
>>
>> [Non-text portions of this message have been removed]
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

That's not a JSLint bug, that's a Javascript-specification bug.  Local variables
are function-scoped and not, as they should be, block-scoped.  The following
function will return "3" when it should return undefined:

(function() {
    if (true) {
      var v = 3;
    }
    if (true) {
       var v;
       return v;
    }
})();


JSLint is pointing out that Javascript will not do what you obviously want.  By
contrast:
(function() {
    var e = "no problem";
    try {
        a();
    } catch(e) {
       return String(e) ;
    }
    return e;
})();


does exactly what you want: returns the text of the exception if one is thrown.



________________________________
From: D Chiesa <dpchiesa@...>
To: jslint_com@yahoogroups.com
Sent: Fri, May 28, 2010 11:09:09 AM
Subject: Re: [jslint] Catch block identifier reuse flagged as error

It does not happen only in catch blocks.
JSLINT will flag the 2nd e in this code as well:

     if (condition1) {
         var e = new Error("This is unacceptable!");
         e.source = "Whatever";
         throw e;
     }

     if (condition2){
         var e = new Error("Some other problem occurred");
         throw e;
     }






From: Joshua
Sent: Friday, May 28, 2010 1:48 PM
To: jslint_com@yahoogroups.com
Subject: [jslint] Catch block identifier reuse flagged as error



The following generates the error "'e' is already defined.":
function f() { try { } catch (e) { } try { } catch (e) { }}
The identifier "e" is bound to the lexical environment of each catch
block, so it is not "already defined" within the scope of the function,
which is what the error seemingly refers to.
A warning for this case makes far more sense:
function f() { var e = 1; try { } catch (e) { } try { } catch
(e) { }}
And JSLint does correctly report two errors. To those unfamiliar with
the language, it would be unclear what "e" refers to at various points
in f. I wholeheartedly endorse a JSLint error in this case!
Likewise, JSLint very correctly reports an error here, where "e" is not
defined outside of the catch block:
function f() { try { } catch (e) { } f(e);}
Now, obviously, one can write this instead:
function f() { try { } catch (e1) { } try { } catch (e2) { }}
... but I'm not convinced that this improves readability; I think it
impairs it by adding unnecessary clutter. Even using the same identifier
name in both catch clauses, the syntax of the program makes it explicit
that inside the second catch block, the identifier "e" can only be
referring to the value thrown by the second try block.
This is minor in the grand scheme of things, and I happily defer to our
benevolent dictator.

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





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



------------------------------------

Yahoo! Groups Links



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

From: D Chiesa <dpchiesa@...>

>  Thank you, I've been enlightened.

Then tell us, does Javascript have a Buddha-nature?

M.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> It would seem that there is a bug in Rhino.
>

I added in my rhino script the following code:

         data = JSLINT.data();
         if (data.unused) {
             for (i = 0; i < data.unused.length; i += 1) {
                 print(filename + ':' + data.unused[i].line + ': ' +
                     'Unused variable \'' + data.unused[i].name + '\'.');
             }
         }

It is quite similar to the code you found in the report function.
Now the unused variables are printed.

I think the web version print the html created by the report function.
This is the difference between rhino and web jslint.

Maybe a call of the warning function would be better, adding an item in errors
array, when an unused variable is detected.

Another approach may be adding a warning array: JSLINT.warnings.

Regards,
Alberto

Would it be possible to have the Good Parts options automatically checked from
entering the page with a URI parameter.  Example:

http://jslint.com/?goodparts

I was thinking maybe adding a simple function that to the webjslint.js that
examines the page location and if the parameter is present the Good Parts button
is automatically triggered upon completion of page load.

My intention is that I would like to be able to link people directly to JSLint
with Good Parts enabled from a tool I am working on.

Thanks
Austin

At work I use JavaScript most of the time to create and maintain HTA
applications on Windows. HTA are html files with an .hta extension and the
addition of an <HTA:APPLICATION ... /> tag within the head element. Written in
html/css/js, HTA behave as native applications; for example, they have
read/write access to the file system.

JSLint does not recognize the HTA:APPLICATION tag and quits. I am used to delete
or comment out the HTA tag, but can JSLint be made to accept it? Or continue
with a security warning instead of aborting?

HTA are documented in MSDN.

I tried to use the parse() function of JSLint to parse the following three
pieces of JavaScript code:
    1. function(b, c){var a = b + c; return a; }
    2. window.addEventListener('click', click_hanlder, true);
    3. document.documentElement.innerHTML;

The outputs are the following:
    1. returns a correct tree.
    2. returns a tree with only one node of "window".
    3. crashes the browser.

I'm wondering whether JSLint doesn't support DOM function.

Here's the the way I used the parse() function, which is copied and pasted from
the JSLint self-parse example, with replacing the "source" variable :

try {
   parse = make_parse();
   var source = "something to parse";//replaced by the three inputs above
   tree = parse(source);
   if (tree) {
     document.write(JSON.stringify(tree, ['key', 'name', 'message',
         'value', 'arity', 'first', 'second', 'third', 'fourth'], 4));
  }
} catch (e) {
   document.write(JSON.stringify(e, ['name', 'message', 'from', 'to', 'key',
         'value', 'arity', 'first', 'second', 'third', 'fourth'], 4));
}

paulur10,

1) If you attempting to access a window object you are not using the DOM.  The
DOM is based upon the document object as the tree root.

2) There exists no such thing, at least in accordance with standards, as
document.documentElement.  Instead try
document.getElementById("theIDvaluehere").innerHTML = "your string to output
here";

Austin
http://prettydiff.com/

> 2) There exists no such thing, at least in accordance with standards, as
document.documentElement. Instead try
document.getElementById("theIDvaluehere").innerHTML = "your string to output
here";

???

It's part of DOM Level 2.

https://developer.mozilla.org/en/DOM/document.documentElement

<https://developer.mozilla.org/en/DOM/document.documentElement>Aseem

On Sat, Jun 12, 2010 at 6:56 PM, Cheney, Edward A SSG RES USAR USARC <
austin.cheney@...> wrote:

>
>
> paulur10,
>
> 1) If you attempting to access a window object you are not using the DOM.
> The DOM is based upon the document object as the tree root.
>
> 2) There exists no such thing, at least in accordance with standards, as
> document.documentElement. Instead try
> document.getElementById("theIDvaluehere").innerHTML = "your string to
> output here";
>
> Austin
> http://prettydiff.com/
>
>


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

--- In jslint_com@yahoogroups.com, "paulur10" <paulur@...> wrote:
>
> I tried to use the parse() function of JSLint to parse the following three
pieces of JavaScript code:
>    1. function(b, c){var a = b + c; return a; }
>    2. window.addEventListener('click', click_hanlder, true);
>    3. document.documentElement.innerHTML;
>
> The outputs are the following:
>    1. returns a correct tree.
>    2. returns a tree with only one node of "window".
>    3. crashes the browser.
>
> I'm wondering whether JSLint doesn't support DOM function.

JSLint's parse function was not intended to be used out of context, and it does
not produce complete parse trees. You would do better to start with
javascript.crockford.com/tdop/

1) The "window" object is usually implemented as the DOM defaultView:

https://developer.mozilla.org/en/DOM:document.defaultView

In addition, although the "window" object itself may not be codified in the
spec, it implements the EventTarget interface, and the addEventListener method
IS part of the DOM spec.

2) document.documentElement is a part of the DOM Core Level 2, as Aseem Kishore
pointed out.

--- In jslint_com@yahoogroups.com, "Cheney, Edward A SSG RES USAR USARC"
<austin.cheney@...> wrote:
>
> paulur10,
>
> 1) If you attempting to access a window object you are not using the DOM.  The
DOM is based upon the document object as the tree root.
>
> 2) There exists no such thing, at least in accordance with standards, as
document.documentElement.  Instead try
> document.getElementById("theIDvaluehere").innerHTML = "your string to output
here";
>
> Austin
> http://prettydiff.com/
>

Two weeks later, I suspect but I am not sure:
Am I the only person who uses JavaScript in HTA?
Does nobody jslint HTA?

Can JSLint be modified to accept HTA scripts or is the workaround (delete or
comment out the HTA tag) recommended?

Joachim


--- In jslint_com@yahoogroups.com, "jpj116" <jpj116@...> wrote:
>
> At work I use JavaScript most of the time to create and maintain HTA
applications on Windows. HTA are html files with an .hta extension and the
addition of an <HTA:APPLICATION ... /> tag within the head element. Written in
html/css/js, HTA behave as native applications; for example, they have
read/write access to the file system.
>
> JSLint does not recognize the HTA:APPLICATION tag and quits. I am used to
delete or comment out the HTA tag, but can JSLint be made to accept it? Or
continue with a security warning instead of aborting?
>
> HTA are documented in MSDN.
>

Joachim
a. You are not the only one. I do it as well.
b. I think you are right. This option should be under "*Assume Windows* "
option.


On Thu, Jun 24, 2010 at 5:30 PM, jpj116 <jpj116@...> wrote:

>
>
>
>
> Two weeks later, I suspect but I am not sure:
> Am I the only person who uses JavaScript in HTA?
> Does nobody jslint HTA?
>
> Can JSLint be modified to accept HTA scripts or is the workaround (delete
> or comment out the HTA tag) recommended?
>
> Joachim
>
>
> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, "jpj116"
> <jpj116@...> wrote:
> >
> > At work I use JavaScript most of the time to create and maintain HTA
> applications on Windows. HTA are html files with an .hta extension and the
> addition of an <HTA:APPLICATION ... /> tag within the head element. Written
> in html/css/js, HTA behave as native applications; for example, they have
> read/write access to the file system.
> >
> > JSLint does not recognize the HTA:APPLICATION tag and quits. I am used to
> delete or comment out the HTA tag, but can JSLint be made to accept it? Or
> continue with a security warning instead of aborting?
> >
> > HTA are documented in MSDN.
> >
>
>
>



--
There's no place like 127.0.0.1
---------------------------------------------


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

Or move your javascript to external files, jslint those, and leave your markup
and tools alone.





________________________________
From: jpj116 <jpj116@...>
To: jslint_com@yahoogroups.com
Sent: Thu, June 24, 2010 7:30:31 AM
Subject: [jslint] Re: JavaScript in HTA applications




Two weeks later, I suspect but I am not sure:
Am I the only person who uses JavaScript in HTA?
Does nobody jslint HTA?

Can JSLint be modified to accept HTA scripts or is the workaround (delete or
comment out the HTA tag) recommended?

Joachim

--- In jslint_com@yahoogroups.com, "jpj116" <jpj116@...> wrote:
>
> At work I use JavaScript most of the time to create and maintain HTA
applications on Windows. HTA are html files with an .hta extension and the
addition of an <HTA:APPLICATION ... /> tag within the head element. Written in
html/css/js, HTA behave as native applications; for example, they have
read/write access to the file system.
>
> JSLint does not recognize the HTA:APPLICATION tag and quits. I am used to
delete or comment out the HTA tag, but can JSLint be made to accept it? Or
continue with a security warning instead of aborting?
>
> HTA are documented in MSDN.





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

My own world:
  Context: I use JavaScript/HTA very frequently.  HTA is wonderful !!!
  Method: Extract the JavaScript and submit that only to JSLint.

On Thu, Jun 24, 2010 at 10:30 AM, jpj116 <jpj116@...> wrote:
>
>
>
> Two weeks later, I suspect but I am not sure:
> Am I the only person who uses JavaScript in HTA?
> Does nobody jslint HTA?
>
> Can JSLint be modified to accept HTA scripts or is the workaround (delete or
comment out the HTA tag) recommended?
>
> Joachim
>
> --- In jslint_com@yahoogroups.com, "jpj116" <jpj116@...> wrote:
> >
> > At work I use JavaScript most of the time to create and maintain HTA
applications on Windows. HTA are html files with an .hta extension and the
addition of an <HTA:APPLICATION ... /> tag within the head element. Written in
html/css/js, HTA behave as native applications; for example, they have
read/write access to the file system.
> >
> > JSLint does not recognize the HTA:APPLICATION tag and quits. I am used to
delete or comment out the HTA tag, but can JSLint be made to accept it? Or
continue with a security warning instead of aborting?
> >
> > HTA are documented in MSDN.
> >
>
>


--
--------------------------
Television and the media culture have replaced thoughtfulness with
entertainment.  We are being converted from a critically minded
inquisitive population enjoying informed discourse to a nation of
passive retards.

JSLint now tolerates <hta:application ...> in the <head> of HTML documents.

Thank you. I appreciate the HTA support.

Joachim

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> JSLint now tolerates <hta:application ...> in the <head> of HTML documents.
>

I've been playing with google closure compiler and experimenting with its code
refactoring capabilities and one of the things I noticed that seems incompatible
here is that I get the warning: The body of a for in should be wrapped in an if
statement to filter unwanted properties from the prototype, when it is in fact
filtered.

example code:
for (b in a) {
	 a.hasOwnProperty(b) && one-line filtered for-in body code here.
}

So far I'm very impressed with the power of Google closure compiler, but it's a
shame that it's such a blunt tool with only 3 configuration options that act
like a slider.  I would really like to see the just the code refactoring without
minification.

I would also like to note that after "reinflating" the fulljslint.js code after
processing it through closure compiler in simple mode, the code from closure
compiler is 548 lines shorter than the fulljslint.js code processed with
jsbeautifier with no empty line preservation.