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";

--- In jslint_com@yahoogroups.com, "montago_2004" <mdk@...> wrote:
> try this :
>
> var p = "eval";

You can turn that off with the Tolerate eval option.

--- In jslint_com@yahoogroups.com, "DoNotSay" <arminx@...> wrote:
>
> 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?

I use /*global / to do that. It is far from ideal, but the language
does not provide an ideal solution.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> --- In jslint_com@yahoogroups.com, "montago_2004" <mdk@> wrote:
> > try this :
> >
> > var p = "eval";
>
> You can turn that off with the Tolerate eval option.
>

Don't you see the error ???
Or do I have to spell it for you ?

var p = "e"+"v"+"a"+"l"; //which also report 'Eval is Evil'

It's a string !, its harmless :-D

--- In jslint_com@yahoogroups.com, "montago_2004" <mdk@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@>
> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "montago_2004" <mdk@> wrote:
> > > try this :
> > >
> > > var p = "eval";
> >
> > You can turn that off with the Tolerate eval option.
> >
>
> Don't you see the error ???
> Or do I have to spell it for you ?
>
> var p = "e"+"v"+"a"+"l"; //which also report 'Eval is Evil'
>
> It's a string !, its harmless :-D

There is no reason to put eval in a string except to evade an eval
restriction, so JSLint is doing its job.

Bill,

Thank you for the response.  I worked backward from it to get to an example of
the problem.  It behaves the same on several hosts: it outputs three 3's. My
original WSH example must have avoided the problem.

http://bencollver.googlepages.com/looptest3.html

Cheers,

Ben

I notice that you recommend in your book not to use substring (and you
don't even mention the deprecated substr) and to use slice instead. I
have the dead tree version of JS:tGP, so I can't quickly search for
those magical words "use YYY instead".

Have you considered changing JSLint to offer such recommendations?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> --- In jslint_com@yahoogroups.com, "montago_2004" <mdk@> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@>
> > wrote:
> > >
> > > --- In jslint_com@yahoogroups.com, "montago_2004" <mdk@> wrote:
> > > > try this :
> > > >
> > > > var p = "eval";
> > >
> > > You can turn that off with the Tolerate eval option.
> > >
> >
> > Don't you see the error ???
> > Or do I have to spell it for you ?
> >
> > var p = "e"+"v"+"a"+"l"; //which also report 'Eval is Evil'
> >
> > It's a string !, its harmless :-D
>
> There is no reason to put eval in a string except to evade an eval
> restriction, so JSLint is doing its job.
>

var Explain = "You should be aware that eval might occur in non-script
context"

//that eval might be a token in a parser
switch(token)
{
    //....
    case "eval" : break;
    //....
}

/*
    And that eval isn't evil, when you use it right.
*/

var ObjCopy = eval( OrgObj.toSource() );

--- In jslint_com@yahoogroups.com, "Jacob Davenport" <jacob@...> wrote:
>
> I notice that you recommend in your book not to use substring (and you
> don't even mention the deprecated substr) and to use slice instead. I
> have the dead tree version of JS:tGP, so I can't quickly search for
> those magical words "use YYY instead".
>
> Have you considered changing JSLint to offer such recommendations?
>

What also would be VERY nice, was warnings (AND I UTTERLY MEAN
WARNING, NOT ERROR) - for any function/pattern which isn't
crossbrowser friendly

some methods are FF-only, some are Opera-only, some are IE-only etc...

a helping hand would be nice...

so "warning", not "error"

> //that eval might be a token in a parser
> switch(token)
> {
>    //....
>    case "eval" : break;

Like I said before, there is an option to turn that check off.
I don't recommend it.

--- In jslint_com@yahoogroups.com, "DoNotSay" <arminx@...> wrote:
>
> 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
>

I had a hellava time figuring this one out. What I did was throw all
of my common functions into a namespace (eg. Common). So for example:

Common = function () {
     functionX = function () {
         ...
     },

     myajaxcall = function () {
         ...
     }
}();

Then you can just refer to these functions as Common.myajaxcall(). On
your other pages, you just put on the top /*global Common */ and that
will tell jslint that Common is an accepted global object. Think of it
as a "class" with "static functions".

Hope that helps.

--- In jslint_com@yahoogroups.com, "Paul" <DWTebriel@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "DoNotSay" <arminx@> wrote:
> >
> > 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
> >
>
> I had a hellava time figuring this one out. What I did was throw all
> of my common functions into a namespace (eg. Common). So for example:
>
> Common = function () {
>     functionX = function () {
>         ...
>     },
>
>     myajaxcall = function () {
>         ...
>     }
> }();
>
> Then you can just refer to these functions as Common.myajaxcall(). On
> your other pages, you just put on the top /*global Common */ and that
> will tell jslint that Common is an accepted global object. Think of it
> as a "class" with "static functions".
>
> Hope that helps.
>

Whoops, omit the parenthesis after the last brace. That assume a
singleton. That isn't needed in this situation.

> I had a hellava time figuring this one out. What I did was throw all
> of my common functions into a namespace (eg. Common). So for example:
>
> Common = function () {
>     functionX = function () {
>         ...
>     },
>
>     myajaxcall = function () {
>         ...
>     }
> }();
>
> Then you can just refer to these functions as Common.myajaxcall(). On
> your other pages, you just put on the top /*global Common */ and that
> will tell jslint that Common is an accepted global object.

I think you meant either

var Common = {
     functionX: function () {},
     myajaxcall: function () {}
};

     or

var Common = function () {
     return {
        functionX: function () {},
         myajaxcall: function () {}
     };
}();

I added a strict option that anticipates the "use strict"; pragma of
ES3.1. If the first statement of a compilation unit is "use strict";
then the JavaScript engine will prohibit use of some of the language's
problematic features. These restrictions are in line with things that
JSLint discourages.