This produces an error:

function a() {
     return (
         doStuff(m, n) +
         "someString"
     );
}

Imagine that the doStuff and someString lines are long, thus the
desire to break them up over several lines.  However, this does not
produce an error:

function a() {
     return (
         "someString" +
         doStuff(m, n)
     );
}

Is the first one actually dangerous in some way that the second one is
not?  Is JavaScript going to stick a semicolon after "someString"
unless it is followed by a plus sign, but not after the doStuff
function call?

Both seem to work in IE6, IE7, and FF.

Thanks again for this great tool.

--- In jslint_com@yahoogroups.com, "Jacob Davenport" <jacob@...> wrote:
>
> This produces an error:
>
> function a() {
>     return (
>         doStuff(m, n) +
>         "someString"
>     );
> }

JSLint does not like to break after a string literal. This is protect
you from semicolon insertion. You can either turn on the sloppy line
breaking option, or you can break you statement differently. For example,

     function a() {
         return doStuff(m, n) +
             "someString";
     }

--- In jslint_com@yahoogroups.com, "Paul" <DWTebriel@...> wrote:
> I currently have code that looks like the following:
>
> <script type="text/javascript">
>  //<![CDATA[
>  ...
>  //]]>
> </script>
>
> Since I'm doing this in xhtml, my IDE likes that tag being there,
> otherwise it blows up on typical xml characters like [<]. However,
> JSLint is returning a statement such as the following:

XHTML is a fiction. If it were real, you wouldn't need to hide the
hideous CDATA overhead behind JavaScript comments. You would do better
to write your code like this:

     <script>
         ....
     </script>

It is smaller, cleaner, faster.

Even better, do not put any script in HTML files. Use script src.
Separate the markup from the behavior. This tends to lead to better
designs. It also can provide better performance because of
opportunities for minification, compression, and caching.

Douglas,

> > function blddrgable()
> > {
> > $j('div.blddrg').draggable("destroy").droppable("destroy");
> > $j('div.blddrg').draggable({opacity:0.8,zIndex:8000,helper:"clone"})
> >         .droppable({accept:'.blddrg',drop:onDropBld});
> > }
> >
> > function onDropBld (e, ui){
>
gboxJSON2("/swapbild",{"von":$j(this).attr("id"),"nach":$j(ui.draggable).attr("i\
d")},function(erg){});
> >     $j(this).swap($j(ui.draggable));
> >     blddrgable();
> >     }
> >
> > "blddrgable()" connects function "onDropBld" to the drop-event of some
> > .divs. That function does some stuff, and after doing it, it calls
> The global trick obviously only works if the functions are global.

It also works with non-global functions, but is an ugly, ugly hack!

> Ideally, you should have no more than one global function, so it is
> not a general solution.
yes. And I am workung hard on restructuring my .js to do exactly that!
your jslint is of GREAT value and a really really big time saver.

> 1) Make gboxJSON2 an inner function of blddrgable.
gboxJSON2 is allready defined outside, so making it inner won't do any
good.

> 2) var gboxJSON2;
>    function blddrgable...

That would be...
var gboxJSON2;
function bllddrgabl ... ondrop:onDropBld

onDropBld=function...

Is there any price to pay for this declaration? IF yes, which price?

best wishes,

Harald

--- In jslint_com@yahoogroups.com, "DoNotSay" <arminx@...> wrote:
> Is there any price to pay for this declaration? IF yes, which price?

It is insignificant.

For the release Aug, 12nd, at line 910 JSLint (run on itself) displays
the message "Unexpected escaped character '<' in regular expression."

...
if (src || (xmode && !(xmode === 'script' || xmode === 'CDATA'))) {
     warningAt("Unexpected comment.", line, character);
} else if (xmode === 'script' && /\<\/script\>/i.test(s)) { // line 910
     warningAt("Unexpected <\/script> in comment.", line, character);
} else if ((option.safe || xmode === 'script') && ax.test(s)) {
     warningAt("Dangerous comment.", line, character);
...

P.S.: if I am annoying, you could stop me. :)

Regards,
Alberto Santini

I added a onevar option. It allows only one var statement per function.

Unused variables are easier to see in the function report.

I removed support for .kon files. Scripts for Yahoo!Widgets are still
supported.

I increased the amount of rigor required of HTML files. Initially,
checking of HTML was minimal, just enough to locate the scripts.
JSLint seems to be evolving into an HTML verifier.

I improved a lot of the checking required for ADsafe.

There are a lot of changes in this update. Please let me know if I
broke anything.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> I added a onevar option. It allows only one var statement per function.
>
> Unused variables are easier to see in the function report.
>
> I removed support for .kon files. Scripts for Yahoo!Widgets are still
> supported.
>
> I increased the amount of rigor required of HTML files. Initially,
> checking of HTML was minimal, just enough to locate the scripts.
> JSLint seems to be evolving into an HTML verifier.
>
> I improved a lot of the checking required for ADsafe.
>
> There are a lot of changes in this update. Please let me know if I
> broke anything.
>

Thanks a lot for this quick update.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> --- In jslint_com@yahoogroups.com, "Arthur Blake" <arthur.blake@>
> wrote:
> >
> > I think he's trying to ask if it is better to use this form:
> >
> > var x,y,z;
> >
> > versus
> >
> > var x;
> > var y;
> > var z;
> >
> > My opinion is yes, because it makes the script smaller and also
> could help
> > reinforce the fact that the var keyword is only at function scope.
>
> Thanks, I get it now. I think it is a good suggestion.
>


The new 'onevar' option can now be used to that

--- In jslint_com@yahoogroups.com, "Fred Lorrain" <yahoo@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@>
> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "Fred Lorrain" <yahoo@> wrote:
> > >
> > > Hello,
> > >
> > > JSLint generate an error if a symbol is not declared.
> > > That's perfect!
> > >
> > > What about generating a warning if a symbol is declared but never
> used?
> > > A switch to turn off this option is welcome too.
> > >
> > > I'm using yuicompressor-2.3.5.jar to compress my scripts and
this tool
> > > typically generate such kind of message:
> > >
> > > [WARNING] The symbol myTH is declared but is apparently never used.
> > > This code can probably be written in a more compact way.
> > > ,myThead=null,myTfoot=null, ---> myTH <---
> > > =null,myDiv=null;this.splitTable
> >
> > JSLint does identify unused variables in the function report. Is hat
> > not enough?
> >
>
> It's fine to have it in the report (I haven't seen it) but imagine I
> have 100 methods in my object.
> For every unused symbol I will have to track the method name and then
> search for the symbol.
>
> If you can at least add the line number in the report it will really
help.
>


In the new release of JSLint the symbol report has been improved to
highlight unused symbols.

Hello,

I'm for sure too strict, too maniac but ...

JSLint is used to validate JavaScript so what about providing perfect
JavaScripts in JSLint?

If you turn on Firebug on the JSLint page (http://www.jslint.com/)
you will get a long list of warnings.

It's not difficult to get ride of them.
Could you please improve the scripts?
Thanks a lot.

Here examples of warnings:

function str does not always return a value
   }\n
json2.js (line 342)
assignment to undeclared variable JSON
   JSON = function () {
json2.js (line 163)
function match does not always return a value
   line=-1;nextLine();from=0;},token:function(){var
b,c,captures,d,depth,high,i,l,l...
webjslint.js (line 30)
anonymous function does not always return a value
   (;;){b=true;c=s.charAt(l);l+=1;switch(c){case'':errorAt("Unclosed
regular expres...
webjslint.js (line 57)
anonymous function does not always return a value
   character+=l;s=s.substr(l);return
it('(regex)',c);case'\\':c=s.charAt(l);if(c<' ...
webjslint.js (line 59)
anonymous function does not always return a value
   c=s.substr(0,l-1);character+=l;s=s.substr(l);return it('(regex)',c);}\n
webjslint.js (line 80)
anonymous function does not always return a value
   return it('(punctuator)',t);default:return
it('(punctuator)',t);}}},skip:functio...
webjslint.js (line 81)
anonymous function does not always return a value
   return it('(punctuator)',t);default:return
it('(punctuator)',t);}}},skip:functio...
webjslint.js (line 81)
anonymous function does not always return a value
   error("Bad assignment.",this);},20);}\n
webjslint.js (line 150)
anonymous function does not always return a value
   error("Bad assignment.",this);},20);}\n
webjslint.js (line 156)
function optionalidentifier does not always return a value
   if(nexttoken.identifier){advance();return token.value;}}\n
webjslint.js (line 160)
function identifier does not always return a value
   if(token.id==='function'&&nexttoken.id==='('){warning("Missing name in
function ...
webjslint.js (line 162)
function statement does not always return a value
   indent=i;scope=s;return r;}\n
webjslint.js (line 174)
function functionparams does not always return a value

for(;;){i=identifier();p.push(i);addlabel(i,'parameter');if(nexttoken.id\
===','){...
webjslint.js (line 302)
anonymous function does not always return a value

advance(')',t);nospace(prevtoken,token);block(true);funct['(breakage)']-\
=1;funct...
webjslint.js (line 326)
reference to undefined property o.predef
   indent.value=o.indent||4;predefined.value=o.predef instanceof
Array?o.predef.joi...
webjslint.js (line 383)
assignment to undeclared variable JSLINT
   "use strict";JSLINT=function(){var
adsafe_id,adsafe_may,adsafe_went,anonname,app...


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

Hello,

Here again your most devoted fan come with an improvement request :D

There some HTML issues on the page http://www.jslint.com/

Very easy to fix, so please let's do it.

line 1 column 1 - Warning: missing <!DOCTYPE> declaration
line 2 column 1 - Warning: <style> inserting "type" attribute
line 148 column 1 - Warning: <script> inserting "type" attribute
line 149 column 1 - Warning: <script> inserting "type" attribute

Thanks

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> --- In jslint_com@yahoogroups.com, "Paul" <DWTebriel@> wrote:
> > I currently have code that looks like the following:
> >
> > <script type="text/javascript">
> >  //<![CDATA[
> >  ...
> >  //]]>
> > </script>
> >
> > Since I'm doing this in xhtml, my IDE likes that tag being there,
> > otherwise it blows up on typical xml characters like [<]. However,
> > JSLint is returning a statement such as the following:
>
> XHTML is a fiction. If it were real, you wouldn't need to hide the
> hideous CDATA overhead behind JavaScript comments. You would do better
> to write your code like this:
>
>     <script>
>         ....
>     </script>
>
> It is smaller, cleaner, faster.
>
> Even better, do not put any script in HTML files. Use script src.
> Separate the markup from the behavior. This tends to lead to better
> designs. It also can provide better performance because of
> opportunities for minification, compression, and caching.
>
Hey thanks for the reply!

For the browsers that support a content-type of
"application/xml+xhtml", is there any advantage for JavaScript when
working with the DOM compared to "text/html"? If not, then yeah I
agree that xhtml, while cool in theory, is sadly fictional.

The only reason I have inline scripting is so that I can pass data
directly into a view page from a controller using monorail. I keep all
event handling and other scripting in separate pages. I would rather
pass it in on the view than do an additional http request for data on
top of the initial one personally. Since our web apps here use xhtml,
I have to use the cdata tags to actually code in real (theoretical?)
xhtml. So I was just wondering if there was a way to suppress those
warnings for those commented cdata tags.

Hello,

I know that break is recommended before a case but it's not mandatory.
In the following example there is nothing wrong, right?

switch (this.layout) {
      case 'calendarmonth2':
         ...
          this.generateMonth = this.generateMonth_finonline;
      case 'calendarmonth':
          this.drawMonthTabs();
          break;
      case 'calendarteaser':
          ...
          break;
      default:
          ...
}

Omitting the break before calendarmonth is done on purpose.
Isn't it the right way to do it?

Maybe the word Warning should be used instead of problem.

Warning at line 732 character 66: Expected a 'break' statement before
'case'.

Instead of

Problem at line 732 character 66: Expected a 'break' statement before
'case'.


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

I created a page with three buttons, a, b, and c.  When you click on a button,
it alerts its number.  I modified the loop to attach an onclick handler to each
input element and alert the index.  They all alert 4 as expected.

I must have misunderstood the instructions.  The page is at
http://bencollver.googlepages.com/looptest.html

Ben


________________________________________________________________________
     Posted by: "Douglas Crockford" douglas@... douglascrockford
     Date: Wed Aug 13, 2008 11:31 am ((PDT))

Create a page with three buttons, a, b, and c. When you click on a
button, it alerts its number. Modify your loop to get each element by
id and attach an onclick handler that alerts the index. If you do it
incorrectly, they will all alert the same wrong number.

--- In jslint_com@yahoogroups.com, "Fred Lorrain" <yahoo@...> wrote:
> I'm for sure too strict, too maniac but ...
>
> JSLint is used to validate JavaScript so what about providing perfect
> JavaScripts in JSLint?
>
> If you turn on Firebug on the JSLint page (http://www.jslint.com/)
> you will get a long list of warnings.

The warnings assume that a lack of understanding on how undefined
works in the language. If you have a Java mentality, they might be
useful. I have a JavaScript mentality.

--- In jslint_com@yahoogroups.com, "Fred Lorrain" <yahoo@...> wrote:
> There some HTML issues on the page http://www.jslint.com/
>
> Very easy to fix, so please let's do it.
>
> line 1 column 1 - Warning: missing <!DOCTYPE> declaration
> line 2 column 1 - Warning: <style> inserting "type" attribute
> line 148 column 1 - Warning: <script> inserting "type" attribute
> line 149 column 1 - Warning: <script> inserting "type" attribute

No thanks. I think DOCTYPE was a mistake. Certainly, requiring type on
script src was a mistake.

--- In jslint_com@yahoogroups.com, "Paul" <DWTebriel@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@>
> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "Paul" <DWTebriel@> wrote:
> > > I currently have code that looks like the following:
> > >
> > > <script type="text/javascript">
> > >  //<![CDATA[
> > >  ...
> > >  //]]>
> > > </script>
> > >
> > > Since I'm doing this in xhtml, my IDE likes that tag being there,
> > > otherwise it blows up on typical xml characters like [<]. However,
> > > JSLint is returning a statement such as the following:
> >
> > XHTML is a fiction. If it were real, you wouldn't need to hide the
> > hideous CDATA overhead behind JavaScript comments. You would do better
> > to write your code like this:
> >
> >     <script>
> >         ....
> >     </script>
> >
> > It is smaller, cleaner, faster.
> >
> > Even better, do not put any script in HTML files. Use script src.
> > Separate the markup from the behavior. This tends to lead to better
> > designs. It also can provide better performance because of
> > opportunities for minification, compression, and caching.
> >
> Hey thanks for the reply!
>
> For the browsers that support a content-type of
> "application/xml+xhtml", is there any advantage for JavaScript when
> working with the DOM compared to "text/html"? If not, then yeah I
> agree that xhtml, while cool in theory, is sadly fictional.
>
> The only reason I have inline scripting is so that I can pass data
> directly into a view page from a controller using monorail. I keep all
> event handling and other scripting in separate pages. I would rather
> pass it in on the view than do an additional http request for data on
> top of the initial one personally. Since our web apps here use xhtml,
> I have to use the cdata tags to actually code in real (theoretical?)
> xhtml. So I was just wondering if there was a way to suppress those
> warnings for those commented cdata tags.

I currently have no plans to support XHTML. Instead, I am improving
the HTML support.

--- In jslint_com@yahoogroups.com, "Fred Lorrain" <yahoo@...> wrote:
> I know that break is recommended before a case but it's not mandatory.
> In the following example there is nothing wrong, right?
>
> switch (this.layout) {
>      case 'calendarmonth2':
>         ...
>          this.generateMonth = this.generateMonth_finonline;
>      case 'calendarmonth':
>          this.drawMonthTabs();
>          break;
>      case 'calendarteaser':
>          ...
>          break;
>      default:
>          ...
> }
>
> Omitting the break before calendarmonth is done on purpose.
> Isn't it the right way to do it?
>
> Maybe the word Warning should be used instead of problem.
>
> Warning at line 732 character 66: Expected a 'break' statement before
> 'case'.
>
> Instead of
>
> Problem at line 732 character 66: Expected a 'break' statement before
> 'case'.

I thought you were supposed to be the too strict, too maniac guy.

See http://yuiblog.com/blog/2007/04/25/id-rather-switch-than-fight/

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> --- In jslint_com@yahoogroups.com, "Fred Lorrain" <yahoo@> wrote:
> > I know that break is recommended before a case but it's not mandatory.
> > In the following example there is nothing wrong, right?
> >
> > switch (this.layout) {
> >      case 'calendarmonth2':
> >         ...
> >          this.generateMonth = this.generateMonth_finonline;
> >      case 'calendarmonth':
> >          this.drawMonthTabs();
> >          break;
> >      case 'calendarteaser':
> >          ...
> >          break;
> >      default:
> >          ...
> > }
> >
> > Omitting the break before calendarmonth is done on purpose.
> > Isn't it the right way to do it?
> >
> > Maybe the word Warning should be used instead of problem.
> >
> > Warning at line 732 character 66: Expected a 'break' statement before
> > 'case'.
> >
> > Instead of
> >
> > Problem at line 732 character 66: Expected a 'break' statement before
> > 'case'.
>
> I thought you were supposed to be the too strict, too maniac guy.
>
> See http://yuiblog.com/blog/2007/04/25/id-rather-switch-than-fight/
>

Thank you very much for the link.
No I understand and accept this rule :D

This rule has now a clear explanation in the messages of JSLint
discussion group :D

I hope all my messages are not flooding the discussion group.
My intention is to provide feedback on most of the nice rules applied
by JSLint.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> --- In jslint_com@yahoogroups.com, "Fred Lorrain" <yahoo@> wrote:
> > I'm for sure too strict, too maniac but ...
> >
> > JSLint is used to validate JavaScript so what about providing perfect
> > JavaScripts in JSLint?
> >
> > If you turn on Firebug on the JSLint page (http://www.jslint.com/)
> > you will get a long list of warnings.
>
> The warnings assume that a lack of understanding on how undefined
> works in the language. If you have a Java mentality, they might be
> useful. I have a JavaScript mentality.
>

Does it mean you will fix them or not ? :D

What means the Problem message ?
Which rule I'm not respecting by using javascript: ?


Problem at line 854 character 33: Script URL.

peopleURL = "javascript:void(popupWindow('" + this.contactsPeoplePath +
...

Do you have a document will all the rules implemented in JSLint that
should be respected and an explanation for all of them ?

Ben,

Another approach:

function main() {
     var arr = ['a', 'b', 'c'];
     var closedValue;
     for (var i = 0; i < 3; i++) {
         closedValue = i;
         document.getElementById(arr[i]).onclick = function(closedValue) {
             alert(closedValue);
         });
     }
}

In your code, this line:
alert(i)
displays the value of i **when the button is clicked**, as opposed to,
**when the function is assigned to onclick.**

For me, the original point - that one needs to take care when defining
functions in a loop - is valid.  Which isn't the same as saying it's never a
good idea.

-- Bill

On Tue, Aug 19, 2008 at 1:40 PM, Ben Collver <tylx@...> wrote:

>   I created a page with three buttons, a, b, and c. When you click on a
> button, it alerts its number. I modified the loop to attach an onclick
> handler to each input element and alert the index. They all alert 4 as
> expected.
>
> I must have misunderstood the instructions. The page is at
> http://bencollver.googlepages.com/looptest.html
>
> Ben
>
> __________________________________________________________
> Posted by: "Douglas Crockford"
douglas@...<douglas%40crockford.com>douglascrockford
> Date: Wed Aug 13, 2008 11:31 am ((PDT))
>
>
> Create a page with three buttons, a, b, and c. When you click on a
> button, it alerts its number. Modify your loop to get each element by
> id and attach an onclick handler that alerts the index. If you do it
> incorrectly, they will all alert the same wrong number.
>
>
>


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

Ben,

Please forgive my previous email which is totally wrong!  The following
actually works (shamelessly copied from Crockford: "The Good Stuff" page
39):

function main() {
     var arr = ['a', 'b', 'c'];
     for (var i = 0; i < 3;  i++) {
         document.getElementById(arr[i]).onclick = function(i) {
             return function (event) {
                 alert(i);
             };
         }(i);
     }
}

Other comments:
(1) The onclick handlers in your HTML <input > elements are overwritten by
main() above, so are not needed..
(2) Your original forEach() function is not used in the above approach.

Sorry about the bum steer!

-- Bill

On Wed, Aug 20, 2008 at 9:24 AM, William Chapman <jeddahbill@...>wrote:

> Ben,
>
> Another approach:
>
> function main() {
>     var arr = ['a', 'b', 'c'];
>     var closedValue;
>     for (var i = 0; i < 3; i++) {
>         closedValue = i;
>         document.getElementById(arr[i]).onclick = function(closedValue) {
>             alert(closedValue);
>         });
>     }
> }
>
> In your code, this line:
> alert(i)
> displays the value of i **when the button is clicked**, as opposed to,
> **when the function is assigned to onclick.**
>
> For me, the original point - that one needs to take care when defining
> functions in a loop - is valid.  Which isn't the same as saying it's never a
> good idea.
>
> -- Bill
>
>
> On Tue, Aug 19, 2008 at 1:40 PM, Ben Collver <tylx@...> wrote:
>
>>   I created a page with three buttons, a, b, and c. When you click on a
>> button, it alerts its number. I modified the loop to attach an onclick
>> handler to each input element and alert the index. They all alert 4 as
>> expected.
>>
>> I must have misunderstood the instructions. The page is at
>> http://bencollver.googlepages.com/looptest.html
>>
>> Ben
>>
>> __________________________________________________________
>> Posted by: "Douglas Crockford"
douglas@...<douglas%40crockford.com>douglascrockford
>> Date: Wed Aug 13, 2008 11:31 am ((PDT))
>>
>>
>> Create a page with three buttons, a, b, and c. When you click on a
>> button, it alerts its number. Modify your loop to get each element by
>> id and attach an onclick handler that alerts the index. If you do it
>> incorrectly, they will all alert the same wrong number.
>>
>>
>>
>
>


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

Hi,

I had a suggestion for a feature for JSLint that I feel would be
pretty useful.

In addition to the options groups ("Good parts" and "Recommended"),
would it be possible to add a couple more groups based off the types
of browsers you would like to support?

Some of the things checked against are there because they are known to
cause problems with certain browsers. It would be useful to have a
button like "IE6+, Firefox 1.5+..etc" which when checked, selects all
the options that should be considered in order to be fairly certain
the code will behave well in those browsers.

Just a thought.

Thanks for the great work that has been done with JSLint :)
Keith

--- In jslint_com@yahoogroups.com, "Keith Hughitt"

> Some of the things checked against are there because they are known
to
> cause problems with certain browsers. It would be useful to have a
> button like "IE6+, Firefox 1.5+..etc" which when checked, selects
all
> the options that should be considered in order to be fairly certain
> the code will behave well in those browsers.

I don't like that idea. JS in web context is for all browsers. There
is either "good" JS following certain rules (which ones might be a
different topic) or "bad" JS voilating them. What's the use of JSLint
not complaining about bad code that is fatal to FF or any other
browser just because user marked "IE6+" checkbox only?
This option would create a rope of sand

(rope if sand is a suggestion of my online translator, dunno if it's
correct) What it means is a felt reliability that isn't really there

--- In jslint_com@yahoogroups.com, "Kai" <blafasel@...> wrote:
> I don't like that idea. JS in web context is for all browsers. There
> is either "good" JS following certain rules (which ones might be a
> different topic) or "bad" JS voilating them. What's the use of JSLint
> not complaining about bad code that is fatal to FF or any other
> browser just because user marked "IE6+" checkbox only?
> This option would create a rope of sand
>
> (rope if sand is a suggestion of my online translator, dunno if it's
> correct) What it means is a felt reliability that isn't really there

I like "rope of sand". That is a good metaphor.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> I increased the amount of rigor required of HTML files. Initially,
> checking of HTML was minimal, just enough to locate the scripts.
> JSLint seems to be evolving into an HTML verifier.
>
> There are a lot of changes in this update. Please let me know if I
> broke anything.
>

ASP uses "<%" and "%>" to delimit areas of server-side ASP code.  As ASP
code can take the form of JScript, I have found JSLint to be a useful
tool for maintaining this code.

With the 2008-08-18 edition, this has become considerably more
inconvenient. I now receive the following error:

Problem at line 1 character 1: Bad identifier %.
<%@Language="VBScript" CodePage=65001 %>

Problem at line 1 character 1: Unrecognized tag '<%>'.
<%@Language="VBScript" CodePage=65001 %>

Problem at line 1 character 1: Stopping, unable to continue. (0%
scanned).

I can work around this by copy-pasting only the necessary portions to
check, but of course, the line numbers no longer match up if I do this.

Previously, the "Tolerate HTML fragments" option would allows these
sorts of files to be checked, and now it won't. I do not know if this
should be "fixed" or not.  Perhaps it is more correct the way it is.  I
do note that Javascript can show up in some very surprising
places--including some places that look like HTML but are not--and this
change reduces the usefulness of JSLint to me.

I also wonder what else may be broken by this.  I know JavaScript can be
used inside SVG files, using the familiar <script> tag.  I tested one of
these with the 2008-08-18 version, and found a similar error message: it
refuses to scan past the <svg> on line one.

Alas.



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

I have structured my Javascript into to files

basicfunctions.js
specialfunctions.js


"basicfunctions.js" gets included allways - as every page of my site
needs something from it

"specialfunctions.js" only gets included on some special pages, as the
functions are only required there.

"basicfunctions.js" also includes stuff like "myajaxcall", which I
reuse in "specialfunctions.js"

NOW ... when jslinting specialfunctions.js, jslint complies, that
"myajaxcall" is not defined. Correct. Because "myajaxcall" (and around
12 more basic functions) are defined in the other file.

ATM I am declaring all those functions as globals within
specialfunctions.js

Is this the best way, or is there something more elegant?

best wishes,

Harald

try this :


var p = "eval";