--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> There is a new option, Tolerate ES5 syntax. If you check this option, JSLint
will accept the new get/set syntax in object literals.
>
> It will require that the get and set functions be declared together, that the
get function have no parameters, and that the set function will have a single
parameter called 'value'.
>
> Please let me know if you find any problems.


option.es5 will now relax the reserved word restriction on object
literals and dot notation, and tolerate a dangling comma, so

     var object = {
         class: x.class,
     };

is accepted.

It seems to me that the trailing comma in object notation is a rather bad coding
practice. I'm fine with JS parsers being able to ignore errors such as these.
But why should a style and syntax checking tool like JSLint be blind to such
sloppy code practices?  Am I missing something with this option? 

-noah

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > There is a new option, Tolerate ES5 syntax. If you check this option, JSLint
will accept the new get/set syntax in object literals.
> >
> > It will require that the get and set functions be declared together, that
the get function have no parameters, and that the set function will have a
single parameter called 'value'.
> >
> > Please let me know if you find any problems.
>
>
> option.es5 will now relax the reserved word restriction on object
> literals and dot notation, and tolerate a dangling comma, so
>
>     var object = {
>         class: x.class,
>     };
>
> is accepted.
>

There is a very good reason to allow for trailing commas (even though IE js
doesn't) -- Consider this 'object' (since we only use it as an associative array
here, we call it a hash):

var hash_example = [
   foo   : 'bar',
   zing  : 'zang',
   one   : 'two'
];

Now lets say I want to reorder the keys so they are alphabetical:

var hash_example = [
   foo   : 'bar',
   one   : 'two'
   zing  : 'zang',
];

Boom.  Instant error -- in two places.  Allowing trailing commas avoids this
problem nicely.

In Perl, a trailing comma is best practice, and omitting the trailing comma is
considered sloppy.

If IE would allow trailing commas, I'd use them consistently.  Since it doesn't,
I use jslint to find the above errors :)



Cheers, Mike



________________________________
From: boyopeg <boyopeg@...>
To: jslint_com@yahoogroups.com
Sent: Tue, April 6, 2010 9:47:41 AM
Subject: [jslint] Re: option.es5


It seems to me that the trailing comma in object notation is a rather bad coding
practice. I'm fine with JS parsers being able to ignore errors such as these.
But why should a style and syntax checking tool like JSLint be blind to such
sloppy code practices?  Am I missing something with this option?

-noah

--- In jslint_com@yahoogro ups.com, "Douglas Crockford" <douglas@... > wrote:
>
> --- In jslint_com@yahoogro ups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > There is a new option, Tolerate ES5 syntax. If you check this option, JSLint
will accept the new get/set syntax in object literals.
> >
> > It will require that the get and set functions be declared together, that
the get function have no parameters, and that the set function will have a
single parameter called 'value'.
> >
> > Please let me know if you find any problems.
>
>
> option.es5 will now relax the reserved word restriction on object
> literals and dot notation, and tolerate a dangling comma, so
>
>     var object = {
>         class: x.class,
>     };
>
> is accepted.
>




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

Whoops.  Need more coffee.  Should be var hash_example = {...}, not [].   But
you get the idea.





________________________________
From: Michael Mikowski <z_mikowski@...>
To: jslint_com@yahoogroups.com
Sent: Tue, April 6, 2010 11:54:25 AM
Subject: Re: [jslint] Re: option.es5


There is a very good reason to allow for trailing commas (even though IE js
doesn't) -- Consider this 'object' (since we only use it as an associative array
here, we call it a hash):

var hash_example = [
   foo   : 'bar',
   zing  : 'zang',
   one   : 'two'
];

Now lets say I want to reorder the keys so they are alphabetical:

var hash_example = [
   foo   : 'bar',
   one   : 'two'
   zing  : 'zang',
];

Boom.  Instant error -- in two places.  Allowing trailing commas avoids this
problem nicely.

In Perl, a trailing comma is best practice, and omitting the trailing comma is
considered sloppy.

If IE would allow trailing commas, I'd use them consistently.  Since it doesn't,
I use jslint to find the above errors :)



Cheers, Mike



________________________________
From: boyopeg <boyopeg@...>
To: jslint_com@yahoogroups.com
Sent: Tue, April 6, 2010 9:47:41 AM
Subject: [jslint] Re: option.es5


It seems to me that the trailing comma in object notation is a rather bad coding
practice. I'm fine with JS parsers being able to ignore errors such as these.
But why should a style and syntax checking tool like JSLint be blind to such
sloppy code practices?  Am I missing something with this option?

-noah

--- In jslint_com@yahoogro ups.com, "Douglas Crockford" <douglas@... > wrote:
>
> --- In jslint_com@yahoogro ups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > There is a new option, Tolerate ES5 syntax. If you check this option, JSLint
will accept the new get/set syntax in object literals.
> >
> > It will require that the get and set functions be declared together, that
the get function have no parameters, and that the set function will have a
single parameter called 'value'.
> >
> > Please let me know if you find any problems.
>
>
> option.es5 will now relax the reserved word restriction on object
> literals and dot notation, and tolerate a dangling comma, so
>
>     var object = {
>         class: x.class,
>     };
>
> is accepted.
>




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

I can see in certain circumstances that trailing commas could be deemed
acceptable, though I'm still of the mindset that this is bad form in most
JavaScript contexts.  I'm failing to see how opting into this practice is linked
to ES5 compatibility though.  Does ES5 specifically dictate that trailing commas
are acceptable?

Rob





________________________________
From: Michael Mikowski <z_mikowski@...>
To: jslint_com@yahoogroups.com
Sent: Tue, April 6, 2010 11:56:46 AM
Subject: Re: [jslint] Re: option.es5


Whoops.  Need more coffee.  Should be var hash_example = {...}, not [].   But
you get the idea.

____________ _________ _________ __
From: Michael Mikowski <z_mikowski@yahoo. com>
To: jslint_com@yahoogro ups.com
Sent: Tue, April 6, 2010 11:54:25 AM
Subject: Re: [jslint] Re: option.es5

There is a very good reason to allow for trailing commas (even though IE js
doesn't) -- Consider this 'object' (since we only use it as an associative array
here, we call it a hash):

var hash_example = [
foo   : 'bar',
zing  : 'zang',
one   : 'two'
];

Now lets say I want to reorder the keys so they are alphabetical:

var hash_example = [
foo   : 'bar',
one   : 'two'
zing  : 'zang',
];

Boom.  Instant error -- in two places.  Allowing trailing commas avoids this
problem nicely.

In Perl, a trailing comma is best practice, and omitting the trailing comma is
considered sloppy.

If IE would allow trailing commas, I'd use them consistently.  Since it doesn't,
I use jslint to find the above errors :)

Cheers, Mike

____________ _________ _________ __
From: boyopeg <boyopeg@gmail. com>
To: jslint_com@yahoogro ups.com
Sent: Tue, April 6, 2010 9:47:41 AM
Subject: [jslint] Re: option.es5

It seems to me that the trailing comma in object notation is a rather bad coding
practice. I'm fine with JS parsers being able to ignore errors such as these.
But why should a style and syntax checking tool like JSLint be blind to such
sloppy code practices?  Am I missing something with this option?

-noah

--- In jslint_com@yahoogro ups.com, "Douglas Crockford" <douglas@... > wrote:
>
> --- In jslint_com@yahoogro ups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > There is a new option, Tolerate ES5 syntax. If you check this option, JSLint
will accept the new get/set syntax in object literals.
> >
> > It will require that the get and set functions be declared together, that
the get function have no parameters, and that the set function will have a
single parameter called 'value'.
> >
> > Please let me know if you find any problems.
>
>
> option.es5 will now relax the reserved word restriction on object
> literals and dot notation, and tolerate a dangling comma, so
>
>     var object = {
>         class: x.class,
>     };
>
> is accepted.





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

--- In jslint_com@yahoogroups.com, Rob Richardson <erobrich@...> wrote:
>
> I can see in certain circumstances that trailing commas could be deemed
acceptable, though I'm still of the mindset that this is bad form in most
JavaScript contexts.  I'm failing to see how opting into this practice is linked
to ES5 compatibility though.  Does ES5 specifically dictate that trailing commas
are acceptable?

ES3 does not allow the trailing comma, so IE is correct when it rejects it.

ES5 allows but does not require the trailing comma.

There is often confusion between separators and terminators. Commas are
separators. Semicolons are terminators.

>  ES3 does not allow the trailing comma, so IE is correct when it rejects
it.

Distinguo: ES3 does not allow the trailing comma, so Internet Explorer is
correct TO reject
it.

IE does the right thing the wrong way.  It rejects the comma and gives an
ambiguous message and the line number BUT NOT THE FILE NAME.

Even assuming Microsoft employees should otherwise be allowed to live, this
transgression (perversely maintained through every version of IE) is alone
grounds for hunting them all down with dogs and shotguns.

M.




________________________________
From: Douglas Crockford <douglas@...>
To: jslint_com@yahoogroups.com
Sent: Tue, April 6, 2010 12:35:27 PM
Subject: [jslint] Re: option.es5

--- In jslint_com@yahoogroups.com, Rob Richardson <erobrich@...> wrote:
>
> I can see in certain circumstances that trailing commas could be deemed
acceptable, though I'm still of the mindset that this is bad form in most
JavaScript contexts.  I'm failing to see how opting into this practice is linked
to ES5 compatibility though.  Does ES5 specifically dictate that trailing commas
are acceptable?

ES3 does not allow the trailing comma, so IE is correct when it rejects it.

ES5 allows but does not require the trailing comma.

There is often confusion between separators and terminators. Commas are
separators. Semicolons are terminators.



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

Yahoo! Groups Links



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

--- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
> Even assuming Microsoft employees should otherwise be allowed to live, this
transgression (perversely maintained through every version of IE) is alone
grounds for hunting them all down with dogs and shotguns.


You are way out of line. Tone it down.

So, would I be correct in surmising that this change from ES3 to ES5 to
allow the trailing comma is for developer convenience as in the
aforementioned reordering example?

Out of curiosity are there any other reasons or examples where this would
come in useful?



On 6 April 2010 21:48, Michael Lorton <mlorton@...> wrote:

>
>
> > ES3 does not allow the trailing comma, so IE is correct when it rejects
> it.
>
> Distinguo: ES3 does not allow the trailing comma, so Internet Explorer is
> correct TO reject
> it.
>
> IE does the right thing the wrong way. It rejects the comma and gives an
> ambiguous message and the line number BUT NOT THE FILE NAME.
>
> Even assuming Microsoft employees should otherwise be allowed to live, this
> transgression (perversely maintained through every version of IE) is alone
> grounds for hunting them all down with dogs and shotguns.
>
> M.
>
> ________________________________
> From: Douglas Crockford <douglas@... <douglas%40crockford.com>>
>
> To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
> Sent: Tue, April 6, 2010 12:35:27 PM
>
> Subject: [jslint] Re: option.es5
>
> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Rob
> Richardson <erobrich@...> wrote:
> >
> > I can see in certain circumstances that trailing commas could be deemed
> acceptable, though I'm still of the mindset that this is bad form in most
> JavaScript contexts. I'm failing to see how opting into this practice is
> linked to ES5 compatibility though. Does ES5 specifically dictate that
> trailing commas are acceptable?
>
> ES3 does not allow the trailing comma, so IE is correct when it rejects it.
>
> ES5 allows but does not require the trailing comma.
>
> There is often confusion between separators and terminators. Commas are
> separators. Semicolons are terminators.
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
> [Non-text portions of this message have been removed]
>
>
>



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


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

It makes reordering easier, editing the list less error-prone, and generating
Javascript from data a little simpler.  Overall, probably a good thing.

M.




________________________________
From: Simon Kenyon Shepard <simon.shepard@...>
To: jslint_com@yahoogroups.com
Sent: Wed, April 7, 2010 5:26:29 AM
Subject: Re: [jslint] Re: option.es5

So, would I be correct in surmising that this change from ES3 to ES5 to
allow the trailing comma is for developer convenience as in the
aforementioned reordering example?

Out of curiosity are there any other reasons or examples where this would
come in useful?



On 6 April 2010 21:48, Michael Lorton <mlorton@...> wrote:

>
>
> > ES3 does not allow the trailing comma, so IE is correct when it rejects
> it.
>
> Distinguo: ES3 does not allow the trailing comma, so Internet Explorer is
> correct TO reject
> it.
>
> IE does the right thing the wrong way. It rejects the comma and gives an
> ambiguous message and the line number BUT NOT THE FILE NAME.
>
> Even assuming Microsoft employees should otherwise be allowed to live, this
> transgression (perversely maintained through every version of IE) is alone
> grounds for hunting them all down with dogs and shotguns.
>
> M.
>
> ________________________________
> From: Douglas Crockford <douglas@... <douglas%40crockford.com>>
>
> To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
> Sent: Tue, April 6, 2010 12:35:27 PM
>
> Subject: [jslint] Re: option.es5
>
> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Rob
> Richardson <erobrich@...> wrote:
> >
> > I can see in certain circumstances that trailing commas could be deemed
> acceptable, though I'm still of the mindset that this is bad form in most
> JavaScript contexts. I'm failing to see how opting into this practice is
> linked to ES5 compatibility though. Does ES5 specifically dictate that
> trailing commas are acceptable?
>
> ES3 does not allow the trailing comma, so IE is correct when it rejects it.
>
> ES5 allows but does not require the trailing comma.
>
> There is often confusion between separators and terminators. Commas are
> separators. Semicolons are terminators.
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
> [Non-text portions of this message have been removed]
>
>
>



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


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



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

Yahoo! Groups Links



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

I'm putting together a presentation to highlight the sort of bugs that JSLint
can help you avoid, I guess this focuses on obvious bugs in code caused by
things like misplaced braces, but also issues that show up when combining and
minifying your js files, e.g. missing semi-colons, function names or variable
names that have been used before, etc.

Can anyone think of some examples that I can include, or better yet, a webpage
that already discusses this kind of thing?

Wouldn't every error message in the jslint.js file suggest an example?  My
biggest one is extra final semicolon;.

M.





________________________________
From: Andrew <adjohns@...>
To: jslint_com@yahoogroups.com
Sent: Mon, April 12, 2010 6:09:06 AM
Subject: [jslint] common issues that jslint can solve

I'm putting together a presentation to highlight the sort of bugs that JSLint
can help you avoid, I guess this focuses on obvious bugs in code caused by
things like misplaced braces, but also issues that show up when combining and
minifying your js files, e.g. missing semi-colons, function names or variable
names that have been used before, etc.

Can anyone think of some examples that I can include, or better yet, a webpage
that already discusses this kind of thing?

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

Hi Doug,

I was curious as to why using "_" in identifiers (e.g. to convey that a function
might be private as opposed to be publicly accessible) is considered bad
practice?

We are currently dealing with legacy code in our project and found that the
previous developers have used "_" quite frequently. It can also be spotted in
YUI code, in the RTE Editor for example:

http://developer.yahoo.com/yui/docs/editor.js.html

Would be great if you could elaborate as to why you think this is something to
avoid.

Thanks,
Klaus

Hi

I'm running a slightly modified jslint over a bunch of our javascript files and
have noticed that if our code defines an array such as

var a = new Array("one","two","three");

Then jslint indicates the error but then terminates further processing with a
" reason=Stopping, unable to continue. (49% scanned) "    message

I can appreciate the array definition could be done better but I'm a bit
perplexed why lint terminates because of it ???
My modifications don't alter the internals of jslint, I just defined a few extra
globals.
In fact when I try a similar test on www.jslint.com the same error shows.

thanks

Tim


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

--- In jslint_com@yahoogroups.com, TIM FULCHER <tfulcher@...> wrote:

> I'm running a slightly modified jslint over a bunch of our javascript files
and have noticed that if our code defines an array such as
>
> var a = new Array("one","two","three");
>
> Then jslint indicates the error but then terminates further processing with a
> " reason=Stopping, unable to continue. (49% scanned) "    message
>
> I can appreciate the array definition could be done better but I'm a bit
perplexed why lint terminates because of it ???


var a = ["one", "two", "three"];

Smaller, faster, better.

Just fix your code.

I have some legacy JavaScript that I am trying to clean up, which of
course involves heavy linting  [;)]

The code was all global, of course, which I have wrapped in:

(function(){...})();

But one of the functions needs to be exposed globally, since I don't
want to modify all the uses of it throughout the application:

Before, it looked like this:
      function FormatMask(inputControl, format, regex){...}

In order to make it global, I added /*global FormatMask */ for JSLint
and then changed the code like this:

      FormatMask = function(inputControl, format, regex){...}

JSLint complains: Problem at line 131 character 5: Read only.

How can I fix this?



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

/*global FormatMask: true */

The ": true" part tells JSLint that that global variable is read-write, not
read-only.

Aseem

On Wed, Apr 21, 2010 at 1:44 PM, g2223060 <g2223060@...> wrote:

>
>
> I have some legacy JavaScript that I am trying to clean up, which of
> course involves heavy linting [;)]
>
> The code was all global, of course, which I have wrapped in:
>
> (function(){...})();
>
> But one of the functions needs to be exposed globally, since I don't
> want to modify all the uses of it throughout the application:
>
> Before, it looked like this:
> function FormatMask(inputControl, format, regex){...}
>
> In order to make it global, I added /*global FormatMask */ for JSLint
> and then changed the code like this:
>
> FormatMask = function(inputControl, format, regex){...}
>
> JSLint complains: Problem at line 131 character 5: Read only.
>
> How can I fix this?
>
> [Non-text portions of this message have been removed]
>
>
>


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

One of my favorites:

{dangling: 'commas',
  'in': 'object literals',
}



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

> Can anyone think of some examples that I can include, or better yet, a webpage
that already discusses this kind of thing?
>

Is that possible?

IMHO, curly braces all over the place, even where they are not needed,
make readability worse. But that's my opinion, and I don't want to
argue.

--- In jslint_com@yahoogroups.com, "Felix E. Klee" <felix.klee@...> wrote:
>
> Is that possible?
>
> IMHO, curly braces all over the place, even where they are not needed,
> make readability worse. But that's my opinion, and I don't want to
> argue.

JSLint can do a much better job for you if you use braces consistently, so you
should use braces consistently. It is good that you do not want to argue.

JSLint doesn't like vendor extensions in pseudo-selectors, even with
the `css` options toggled.

I'm thinking specifically of `button:-moz-focus-inner`, which I'm
finding necessary to standardize a 3px-padding in Gecko's rendering of
buttons that's otherwise impossible to get rid of ( see
http://stopdesign.com/archive/2009/02/04/recreating-the-button.html#comment-4379
).  If you've got time to take a look, I'd like to see the following
snippet parse correctly:

     @charset "UTF-8";
     button::-moz-focus-inner {
         padding: 0;
         border-style: none;
     }

I've hacked together a workaround in my local copy, but I think it's
something that ought be addressed upstream.

Thanks for taking a look!

-Mike

I disagree.  Vendor specific CSS extensions are generally bad practice with
regards to conformance and efficient of CSS payload size.  The Mozilla specific
extensions are no better or worse than the IE specific hacks, which I absolutely
detest.  If JSLint wonders down this road it may never find its way back.

Austin

----- Original Message -----
From: Mike West <mike@...>
Date: Monday, April 26, 2010 17:32
Subject: [jslint] Vendor extensions in pseudoclasses
To: jslint_com@yahoogroups.com


> JSLint doesn't like vendor extensions in pseudo-selectors, even with
> the `css` options toggled.
>
> I'm thinking specifically of `button:-moz-focus-inner`, which I'm
> finding necessary to standardize a 3px-padding in Gecko's
> rendering of
> buttons that's otherwise impossible to get rid of ( see
> http://stopdesign.com/archive/2009/02/04/recreating-the-
> button.html#comment-4379
> ).  If you've got time to take a look, I'd like to see the following
> snippet parse correctly:
>
>    @charset "UTF-8";
>    button::-moz-focus-inner {
>        padding: 0;
>        border-style: none;
>    }
>
> I've hacked together a workaround in my local copy, but I think it's
> something that ought be addressed upstream.
>
> Thanks for taking a look!
>
> -Mike

Hi Douglas, I've got an idea here.
I don't know if you've already considered it, but you seem to have implemented
this idea to some degree with locating declared but unused variables in the
code.
But what would make lint so much more effective would be to locate objects that
have been declared and used, but in no way contribute to the return(s) of the
function(s).

Such an example, where the lint issues no warning:

function test() {
     var i, k;
     k = i + 1;
     i += 1;
     return i;
}

Do you have any plans for including a mapping of precedences and dependencies at
the variable level, or can you recommend a tool that does this?

On Mon, Apr 26, 2010 at 10:08 PM, Cheney, Edward A SSG RES USAR USARC
<austin.cheney@...> wrote:

> The Mozilla specific extensions are no better or worse than the
> IE specific hacks, which I absolutely detest.

1.  How do you feel about `img { -ms-interpolation-mode: bicubic; }`?
How about `-moz-border-radius`, etc?

2.  I'd argue that it's better to use standards-based expansion
mechanisms (vendor extensions are codified in the spec, and their
cross-browser behavior is clearly specified (that is, they're ignored
entirely, possibly invalidating the entire selector).  That's much
less risky than something like the star hack, or the miserable comment
hacks in earlier browsers.  In short, they're not _hacks_.

3.  Practically, there's no way of modifying 3 pixels of padding in
buttons rendered by Gecko.  Gecko provides a pseudo element that
allows manipulation of those three pixels.

-Mike

There are several different rendering engines available on the web.  They each
process presentation differently even when in full conformance to the
specification.  There is no reason to suggest then that a page must appear
identically in every detail in every browser.  All that really matter is that
branding is accurately preserved on all browser, the content remains accessible
to persons with mobility disabilities, and the content remains legible to visual
users.  Everything else is a luxury that demands your extra effort or
nonconforming code that will not pass through any validator.

Austin

----- Original Message -----
From: Mike West <mike@...>
Date: Tuesday, April 27, 2010 2:23
Subject: Re: [jslint] Vendor extensions in pseudoclasses
To: jslint_com@yahoogroups.com


> On Mon, Apr 26, 2010 at 10:08 PM, Cheney, Edward A SSG RES USAR USARC
> < wrote:
>
> > The Mozilla specific extensions are no better or worse than the
> > IE specific hacks, which I absolutely detest.
>
> 1.  How do you feel about `img { -ms-interpolation-mode: bicubic; }`?
> How about `-moz-border-radius`, etc?
>
> 2.  I'd argue that it's better to use standards-based expansion
> mechanisms (vendor extensions are codified in the spec, and their
> cross-browser behavior is clearly specified (that is, they're ignored
> entirely, possibly invalidating the entire selector).  That's much
> less risky than something like the star hack, or the miserable comment
> hacks in earlier browsers.  In short, they're not _hacks_.
>
> 3.  Practically, there's no way of modifying 3 pixels of padding in
> buttons rendered by Gecko.  Gecko provides a pseudo element that
> allows manipulation of those three pixels.
>
> -Mike

On Tue, Apr 27, 2010 at 10:55 AM, Cheney, Edward A SSG RES USAR USARC
<austin.cheney@...> wrote:

> There is no reason to suggest then that a page must appear identically
> in every detail in every browser.

Quite true.  This, however, is an argument against expending too much
effort in pursuit of pixel-perfection.  It's not an argument against
mechanisms that make that goal possible at all.

I think I can safely agree with pretty much everything you've written
in this email while at the same time maintaining that vendor-specific
enhancements and fixes are completely in keeping with the spirit of
the standard.  :)

-Mike

I see value in a lint tool for CSS that could be triggered to accept / reject
vendor-specific rendering rules, and a second trigger to accept / reject the
myriad of star and slash necessary to trigger specific browsers from a single
stylesheet.  It'd be nice also to validate to a specific CSS spec: 2.1, 3.0,
etc.  I don't believe JSLint is that tool.  I'd be comfortable if JSLint could
be driven to ignore anything between .  Of course if JSLint became a lint tool
for CSS checking, I'd love it.  I'd also love if it had options for HTML
validation -- match the doctype found, match a specified doctype, insure script
tags don't self-close, optionally validate HTML 5 inclusion/exclusion, insure
nested object tags necessary for most browsers, etc, etc.  Alas, I think the
going consensus is (with small exception) JSLint is best as a JavaScript lint
tool, and not intended to be an all-in-wonder web verifier. 
http://validator.w3.org/ does the HTML,
  http://jigsaw.w3.org/css-validator/ does the CSS, though both are best as
online tools and don't really support off-line without linux.  Since the 3 types
of content should be in separate files, in theory they can be validated
separately.

Mike, to that end, put this offending CSS in an external stylesheet.  Then
JSLint will only validate you have a well-formed link tag, and leave your CSS
preferences alone.  Granted, we could fuel the discussion of the stylistic
merits ad nauseum, but I think you've made it clear that's not the answer you're
looking for.

Mike,




________________________________
From: Mike West <mike@...>
To: jslint_com@yahoogroups.com
Sent: Mon, April 26, 2010 6:01:48 AM
Subject: [jslint] Vendor extensions in pseudoclasses


JSLint doesn't like vendor extensions in pseudo-selectors, even with
the `css` options toggled.

I'm thinking specifically of `button:-moz- focus-inner` , which I'm
finding necessary to standardize a 3px-padding in Gecko's rendering of
buttons that's otherwise impossible to get rid of ( see
http://stopdesign. com/archive/ 2009/02/04/ recreating- the-button.
html#comment- 4379
).  If you've got time to take a look, I'd like to see the following
snippet parse correctly:

@charset "UTF-8";
button::-moz- focus-inner {
padding: 0;
border-style: none;
}

I've hacked together a workaround in my local copy, but I think it's
something that ought be addressed upstream.

Thanks for taking a look!

-Mike





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

On Tue, Apr 27, 2010 at 5:40 PM, Rob Richardson <erobrich@...> wrote:

> Alas, I think the going consensus is (with small exception) JSLint is best as
> a JavaScript lint tool, and not intended to be an all-in-wonder web verifier.

I understand that, and also see value in concentrating effort on the
areas in which JSLint most clearly shows value.  I wasn't expecting to
get into an argument about the appropriateness of CSS I'm writing,
this obviously isn't the correct forum for that discussion.  This will
be my last message on the topic.

My point is simple.  JSLint does, at the moment, parse CSS.  It
attempts to validate CSS in a very practical way (that is, it accepts
CSS with the conventional hacks that are necessary to do work on
today's web) in a way that the CSS Validator doesn't.  That's valuable
to me, and I think it's generally valuable.

The inconsistency I've run into, which is solved via the vendor
extension, falls into the same category of practical resolutions to
problems with cross-browser web development.  Further, it's consistent
with JSLint's current acceptance of vendor extensions for properties
(the IE resize mode I noted yesterday, for example, passes linting).
I'd recommend that support be added into JSLint for these types of
pseudoclasses as well.

In the hopes of helping someone else work around the issue, I'll note
the 7-line change that I'm using locally below.  I don't think it's
the _right_ way to add the functionality, but it works for me.

Thanks!

-Mike

--- Diff follows, though line numbers won't line up with the current
version... ---

diff --git a/scripts/lib/jslint.js b/scripts/lib/jslint.js
index 05a2283..f270620 100644
--- a/scripts/lib/jslint.js
+++ b/scripts/lib/jslint.js
@@ -884,7 +884,7 @@ var JSLINT = (function () {
  // url badness
          ux = /&|\+|\u00AD|\.\.|\/\*|%[^;]|base64|url|expression|data|mailto/i,
  // style
-        sx =
/^\s*([{:#%.=,>+\[\]@()"';]|\*=?|\$=|\|=|\^=|~=|[a-zA-Z_][a-zA-Z0-9_\-]*|[0-9]+|\
<\/|\/\*)/,
+        sx =
/^\s*([{:#%.=,>+\[\]@()"';]|\*=?|\$=|\|=|\^=|~=|[a-zA-Z_\-][a-zA-Z0-9_\-]*|[0-9]\
+|<\/|\/\*)/,
          ssx =
/^\s*([@#!"'};:\-%.=,+\[\]()*_]|[a-zA-Z][a-zA-Z0-9._\-]*|\/\*?|\d+(?:\.\d+)?|<\/\
)/,
  // attributes characters
          qx = /[^a-zA-Z0-9-_\/ ]/,
@@ -3367,8 +3367,12 @@ loop:   for (;;) {
                      advance(')');
                      break;
                  default:
-                    warning("Expected a pseudo, and instead saw :{a}.",
-                        nexttoken, nexttoken.value);
+                    if ( option.css && nexttoken.value[ 0 ] === '-' ) {
+                        advance();
+                    } else {
+                        warning("Expected a pseudo, and instead saw :{a}.",
+                            nexttoken, nexttoken.value);
+                    }
                  }
                  break;
              case '#':

"between ." came from "between style tags" except I conveyed it as markup. The
markup apparently got trimmed by my email program.  What a wonderful world where
we converse in HTML about HTML and our tools get confused on which we meant.  :D

Rob





________________________________
From: Rob Richardson <erobrich@...>
To: jslint_com@yahoogroups.com
Sent: Tue, April 27, 2010 8:40:56 AM
Subject: Re: [jslint] Vendor extensions in pseudoclasses


I see value in a lint tool for CSS that could be triggered to accept / reject
vendor-specific rendering rules, and a second trigger to accept / reject the
myriad of star and slash necessary to trigger specific browsers from a single
stylesheet.  It'd be nice also to validate to a specific CSS spec: 2.1, 3.0,
etc.  I don't believe JSLint is that tool.  I'd be comfortable if JSLint could
be driven to ignore anything between .  Of course if JSLint became a lint tool
for CSS checking, I'd love it.  I'd also love if it had options for HTML
validation -- match the doctype found, match a specified doctype, insure script
tags don't self-close, optionally validate HTML 5 inclusion/exclusion , insure
nested object tags necessary for most browsers, etc, etc.  Alas, I think the
going consensus is (with small exception) JSLint is best as a JavaScript lint
tool, and not intended to be an all-in-wonder web verifier. http://validator.
w3.org/ does the HTML,
http://jigsaw. w3.org/css- validator/ does the CSS, though both are best as
online tools and don't really support off-line without linux.  Since the 3 types
of content should be in separate files, in theory they can be validated
separately.

Mike, to that end, put this offending CSS in an external stylesheet.  Then
JSLint will only validate you have a well-formed link tag, and leave your CSS
preferences alone.  Granted, we could fuel the discussion of the stylistic
merits ad nauseum, but I think you've made it clear that's not the answer you're
looking for.

Rob





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

On Tue, Apr 27, 2010 at 12:43 PM, Rob Richardson <erobrich@...> wrote:
> http://validator. w3.org/ does the HTML,
> http://jigsaw. w3.org/css- validator/ does the CSS,
> though both are best as online tools and don't really support off-line without
linux.

I'm surprised to hear you say that these only run on linux, as I am
able to do command-line validation of CSS and HTML on Windows and Mac
as well.

Great instructions on setting up the w3 CSS validator for use on the
command line, are to be found in the EmacsWiki:
http://www.emacswiki.org/emacs/FlymakeCSS

And Tidy is an excellent command-line tool for HTML validation. It's
included with Cygwin, Macports or Fink.  Tidy is technically a linter,
not a validator, but in practice it catches all the issues that the w3
validation service does.
http://www.w3.org/People/Raggett/tidy/

And if you really want true SGML validation, just like the w3
validation service, there is onsgmls.  It's also included with Cygwin,
Macports and Fink; but you'd also need to grab the w3's DTD library (
http://validator.w3.org/sgml-lib.tar.gz ) and then learn how to invoke
the tool properly.  IMO Tidy is much easier to use and onsgmls doesn't
provide any extra value, but if you really want to use onsgmls, these
links should get you started in the right direction:
http://onemorebug.com/blog/2007/10/28/html-validation/
http://snipplr.com/view/4970/validate-xhtml-with-tidy-andor-openjade-just-like-t\
he-ff-extension/

I hope this information is helpful to others, and that I've not
strayed too far off-topic.

--
Noah Sussman
Software Historian
@noahsussman

A foolish consistency is the hobgoblin of little minds
       -- Emerson