= 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.More straightforward to use the W3C's CSS validator for that: http://jigsaw.w3.org/css-validator/#validate_by_uri+with_opt...
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.
I could make layout a ticking time bomb just by using one shrink-wrapped floated column without clear.
I could make mess of an entire site with just:
.left {float:left}
(which I've seen used in practice)And I can write perfectly maintainable code with lots of floats if I have them sized and cleared properly.
Really, honestly, what does this even mean?
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.
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.
Disclaimer: I am maintainer of JSHint, a fork of JSLint.