JSLint Reports on last 2 Production Versions of jQuery
in [JavaScript]
|
Prev: FAQ Entry Proposal: What is (function(){ /*...*/ })() ?
Next: FAQ Topic - What is Ajax? (2010-03-01)
From: Stefan Weiss on 2 Mar 2010 07:40 On 02/03/10 06:54, David Mark wrote: > Stefan Weiss wrote: >> | * "Expected an assignment or function call and instead saw an >> | expression." - There are two areas in which we access a property with >> | seemingly no side effect, those are: >> | >> | o parent.selectedIndex; (or similar) this is due to the fact that >> | WebKit mis-reports the default selected property of an option, >> | accessing the parent's selectedIndex property fixes it. >> >> David mentioned there was a better way to work around this, but I'm not >> sure what he was referring to. > > The "issue" is that prior to the DOM being ready (or for SELECT's that > have yet to be appended to the DOM), in some browsers, the - selected - > property of the first contained OPTION element will not be set _unless_ > it has a SELECTED attribute (which would only be an issue if _none_ of > the other options is selected, either by attribute or memorized user > intervention). Of course, at least one OPTION should have a SELECTED > attribute. But regardless, the selectedIndex property invariably > reveals which option is selected, so it is trivial to determine if a > random OPTION is selected or not by checking the value of that property. > This was explained to Resig (by proxy of course) and then re-explained > (at least one time). Somehow he decided that his mystical incantation > was more "concise" (meaning less _lines_ of code) and therefore it > remains today (four times over at this point due to duplication and the > possibility of the parentNode being an OPTGROUP). It's funny that even > JSLint recognized it as silly and he deflected its advice as well. > Hopeless. :( Thanks for the explanation. I agree that it's a bad idea to rely on the side effects of a property access. Apart from the style and the JSLint warning, a script engine or a minifier might decide that the line is just empty ballast, and skip it. Somehow this never came up on the pages I worked with - probably because I never tried to read a SELECT before the DOM was ready, and when I've got a SELECT which isn't part of the document, I usually know in advance which option will be selected. We also rarely write the <select> ... </select> HTML by hand; it's almost always generated by some method (or TagLib) which ensures that one of the options has a 'selected' attribute. -- stefan
From: David Mark on 2 Mar 2010 08:36 Stefan Weiss wrote: > On 02/03/10 06:54, David Mark wrote: >> Stefan Weiss wrote: >>> | * "Expected an assignment or function call and instead saw an >>> | expression." - There are two areas in which we access a property with >>> | seemingly no side effect, those are: >>> | >>> | o parent.selectedIndex; (or similar) this is due to the fact that >>> | WebKit mis-reports the default selected property of an option, >>> | accessing the parent's selectedIndex property fixes it. >>> >>> David mentioned there was a better way to work around this, but I'm not >>> sure what he was referring to. >> The "issue" is that prior to the DOM being ready (or for SELECT's that >> have yet to be appended to the DOM), in some browsers, the - selected - >> property of the first contained OPTION element will not be set _unless_ >> it has a SELECTED attribute (which would only be an issue if _none_ of >> the other options is selected, either by attribute or memorized user >> intervention). Of course, at least one OPTION should have a SELECTED >> attribute. But regardless, the selectedIndex property invariably >> reveals which option is selected, so it is trivial to determine if a >> random OPTION is selected or not by checking the value of that property. >> This was explained to Resig (by proxy of course) and then re-explained >> (at least one time). Somehow he decided that his mystical incantation >> was more "concise" (meaning less _lines_ of code) and therefore it >> remains today (four times over at this point due to duplication and the >> possibility of the parentNode being an OPTGROUP). It's funny that even >> JSLint recognized it as silly and he deflected its advice as well. >> Hopeless. :( > > Thanks for the explanation. I agree that it's a bad idea to rely on the > side effects of a property access. Apart from the style and the JSLint > warning, a script engine or a minifier might decide that the line is > just empty ballast, and skip it. Exactly. I once had to do something similar in a widget to force a re-calculation of offsetHeight/Width and it turned out that it required an assignment (or something like that) to take effect in all of the browsers that displayed the delayed update. > > Somehow this never came up on the pages I worked with - probably because > I never tried to read a SELECT before the DOM was ready, and when I've > got a SELECT which isn't part of the document, I usually know in advance > which option will be selected. We also rarely write the <select> ... > </select> HTML by hand; it's almost always generated by some method (or > TagLib) which ensures that one of the options has a 'selected' attribute. > > Yes, it's one of those very rare things that is inexplicably taking up space in a library that can't deal with very common problems. The thing gets cobbled together one observation (often accompanies by a misinterpretation) at a time. At that rate, maybe they will fill in the remaining pieces to the MSHTML "puzzle" by 2020. :)
From: lorlarz on 2 Mar 2010 10:54 On Mar 2, 3:28 am, Gregor Kofler <use...(a)gregorkofler.com> wrote: > lorlarz meinte: > > > I am a long time JavaScripter > > Then it shouldn't be a problem to interpret the JSLint output yourself. > Why did you start this thrad? > > Gregor > > --http://www.gregorkofler.com It is just this stinkin' regular expression stuff I had to comment out a couple days ago which I would still like to hear about: (What are the 'big problems' JSLint sees with these and how do you fix them correctly, maintaining the full intended meaning??): /* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== null ) { soFar = m[3]; parts.push( m[1] ); if ( m[2] ) { extra = m[3]; break; } } */ and // replace(/=([^="'>\s]+\/)>/g, '="$1">') and // jsre = /=\?(&|$)/,
From: Stefan Weiss on 2 Mar 2010 12:15 On 02/03/10 16:54, lorlarz wrote: > On Mar 2, 3:28 am, Gregor Kofler <use...(a)gregorkofler.com> wrote: >> lorlarz meinte: >> >> > I am a long time JavaScripter >> >> Then it shouldn't be a problem to interpret the JSLint output yourself. >> Why did you start this thrad? > It is just this stinkin' regular expression stuff I had > to comment out a couple days ago which I would still > like to hear about: (What are the 'big problems' JSLint > sees with these and how do you fix them correctly, > maintaining the full intended meaning??): > /* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== null ) { The fact that "chunker" references a RegExp has nothing to do with the JSLint warnings. JSLint's parser doesn't understand the comma operator here; it can't make head or tails of the condition syntax, and exits with an error ("unable to continue"). That's most likely because this usage of the comma operator isn't part of Crockford's Good Parts. The solution is to refactor the while loop, for example by replacing it with do...while. > // replace(/=([^="'>\s]+\/)>/g, '="$1">') > > and > > // jsre = /=\?(&|$)/, JSLint: "A regular expression literal can be confused with '/='". The author of JSLint thinks that the /= operator could be confused with the start of these regular expression literals. To eliminate the warning, escape the "=": replace(/\=([^="'>\s]+\/)>/g, '="$1">') jsre = /\=\?(&|$)/, -- stefan
From: Antony Scriven on 2 Mar 2010 12:27
On Mar 2, 3:54 pm, lorlarz <lorl...(a)gmail.com> wrote: > [...] > > It is just this stinkin' regular expression stuff I had > to comment out a couple days ago which I would still > like to hear about: (What are the 'big problems' JSLint > sees with these and how do you fix them correctly, > maintaining the full intended meaning??): Looks to me like the big problems are just style warnings. Though in a large project bad style can become a problem over time. > /* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== null ) { > soFar = m[3]; > > parts.push( m[1] ); > > if ( m[2] ) { > extra = m[3]; > break; > } > } > */ Probably complaining about the comma used as an operator. Good advice, I'd say. > and > > // replace(/=([^="'>\s]+\/)>/g, '="$1">') > > and > > // jsre = /=\?(&|$)/, JSLint is, IMHO, too zealous with its treatment of regexps. Try escaping the '='s. I think the theory behind this is to prevent human parsers from confusing the start of the regexp with the /= operator. These issues are mentioned, albeit tersely, in the instructions. I'm also assuming you had all options cleared since you haven't specified otherwise. --Antony |