This bullshit assertion is getting tiring. JSHint is not "designed to be more configurable", it's JSLint with a different (and more permissive) base configuration.
So when TFAA writes:
> For instance, of the three following if statements, only one is acceptable in JSLint:
TFAA is not disingenuous, TFAA is actively lying. How do I know? Because I read the documentation and I know that setting the `eqeq` option lets you use `==` and `!=` and that setting the `white` option will stop JSLint from caring about how you whitespace-separate your tokens, making all three styles "acceptable to JSLint".
You may not be arsed to configure your tools to match your personal desires, but don't lie about them, that's unbecoming.
 at its core, things may have changed and JSHint may have diverged further from JSLint, that does not seem to be the case when superficially checking their respective online demos.
This can't be turned off without modifying the JSLint parsing process.
(Yes, this is a rather odd bit of code, and it definitely should be flagged up normally. This is from a project where invoking a constructor would add the object to its parent object and trigger a GUI update.)
This statement is fairly meaningless if it's reduced down to "if there's some set of configuration options to JSLint that allows this code to pass, then it's OK." Crockford clearly meant that people should evaluate library quality by the default configuration of JSLint.
"TFAA is not disingenuous, TFAA is actively lying. How do I know?"
Reread the section. I have made it abundantly clear that this only applies if the default values are used.