There's opinionated, and there's badly-thought-out. From the article:
= Don’t use too many floats =
Arbitrary, and impossible to test for. All Lint is
doing is counting how many times you declare "float"
in a stylesheet. It doesn’t matter that you may only
ever use one float on a given page.
I agree with Wilcox on this; between that, "Don't qualify headings" and "Don’t use IDs in selectors", I'm not crash-hot on using CSSLint for anything other than plain syntax checking.
I don't think the "Don't use too many floats" is meant to say anything about performance, but about maintenance.
I think the point is, that if you have to put "float" in lots of declaration, you're missing some abstractions in your css. Most likely a grid plus some classes for inline lists.
Again, CSS Lint is very opinionated, and some of it opinions are contrary to various best practices (especially the fundamentalist approach to not let any classes in the HTML have anything to do with presentation). But from the perspective of these opinions based on how to write maintainable CSS and HTML for large sites, the rules makes a lot of sense.
It gives a float warning. Seems reasonable to me. A warning doesn't mean you have to change anything it just means you might want to look at this. If you understand your code and know that the multiple floats are there on purpose then there's nothing more to do. Like someone else said this is a "perhaps you should be using a proper grid" warning.
I'll quote something from CSS lint I've quoted here before and probably will have to quote again; "CSS Lint simply checks to see if you've used float more than 10 times, and if so, displays a warning. Using this many floats usually means you need some sort of abstraction to achieve the layout.".
"CSS Lint simply checks to see if you've used float more than 10 times, and if so, displays a warning. Using this many floats usually means you need some sort of abstraction to achieve the layout."
I suspect this means you should be using a grid system, either hand written or borrowed from somewhere that writes grid systems. Constantly using float everywhere is completely unnecessary for larger sites.
I think the point is that if you are using floats in too many places you there are probably a whole host of other problems with your CSS. If you took the time to go over your CSS, and find where you are duplicating effort you might be able to reduce the number of CSS classes you are using by finding a common pattern. Thus abstracting your CSS.
True but that's because Javascript has at-once more glaringly obvious flaws to work around and also a lot more applicable software engineering experience out in the wild.
CSS is just hard. For small sites, early stage startups, and personal blogs it is relatively easy. You can organize your CSS along many different axes; the "optimal" CSS structure depends on the exact size and architecture of a site at a specific point in time. This is why there was an early backlash against CSS grid systems when they started to come out, because purists saw it as diluting the semantic value of the markup, but they missed the fact that when sites grow you need an abstraction.
What Nicole Sullivan does is tackle CSS nightmares at their worst: in massive sites like Facebook. In this kind of environment 90% of what you read about CSS best practices is garbage because 90% of people writing about CSS aren't working on sites this big. Actually to get a lot of exposure and become a CSS guru you have to work on a breadth of sites, probably in some kind of consulting or agency context, which tends to be orthogonal to long-term maintenance concerns.
I've heard Nicole speak, and I've also maintained 10k+ LOC of CSS before, and I can attest that she really really knows what she's talking about, and I believe in OOCSS for massive sites. For most sites though, it's probably unnecessary and overkill. The other tricky thing is that you can't do OOCSS effectively until your design is somewhat established and the visual language is clear. Therefore I agree CSSLint is much less useful in general than JSLint, but it's a tool I'd keep in your back pocket for sure.
I agree on the large CSS issue, the problem is one of naming rather than one of utility. The tool is of use to a small audience, JSLint is of use to anyone writing really any JS.
Perhaps there is room for a CSSLint fork that would more easily allow one to pick & choose the opinions they actually care to consider, a la http://jshint.com/ (a jslint fork).
I disagree about JSLint. I can argue that things like failing with fatal error when you don't move all your variable declaration to the top of the function is a bad idea. In the end, all lint programs are just tools to make your life easier. And you should never blindly rely on any of them.
Disclaimer: I am maintainer of JSHint, a fork of JSLint.
