This hole "debacle" could have been avoided if Nicole Sullivan had simply called this tool "OO-CSS check" rather than "CSSLint". Then I'd have no problem with it at all. If you like and apply the OO-CSS method, then clearly this tool can be of some use.
If you, on the other hand, have never heard of OO-CSS, or just disagree with that method, then CSSLint becomes crazy talk, absolutely bat shit crazy talk.
From the introduction of lint's man page: "The lint utility attempts to detect features of the named C program files that are likely to be bugs, to be non-portable, or to be wasteful."
The recommendations singled out by the article go beyond these rules to delve into opinions about CSS best practices. The CSS Lint name is thus IMO misleading. It would be better called OO-CSS Lint.
= 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.
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:
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.
I, myself, have written many rules that I personally would never apply to my own codebase, but perhaps someone else might. My belief is that the world can benefit from static analysis tools and that adoption will be faster if we focus on providing as many rules as possible even if some are (in my opinion) questionable.
So CSS-Lint can be configured to only enforce the rules you want. If a user can find 5-10 rules that they like, then it seems like a good idea to start using the tool, especially if the team is larger and less highly skilled. But it seems petty to me to lambast a project just because you disagree with the name. Yes the intent of CSS-Lint is something different than base Lint, but I can say from experience that people looking for static analysis tools often google for "css lint" or "java lint" before understanding that Lint is a product and Static Analysis is the general term.
To summarize: CSS-Lint is just a name and the product is aggressively marketed. That doesn't mean it can't be useful.
>Don’t use IDs in selectors
>They are the fastest way a browser can select a given element.
Yes and no. Using an ID to get an element via JS is fast, undeniably so. But the difference in selecting by ID vs. Class in CSS is so minuscule it's hardly worth mentioning. If you're styling an element based on an ID used by JS, congratulations, you've just needlessly coupled JS and CSS.
>Performance at the cost of everything else. Performance as the altar at which all the other benefits of CSS are sacrificed.
Be more dramatic. OOCSS's primary benefit is to minimize maintenance and reduce CSS filesize. File transfer is the second biggest culprit of page load times. I hardly see optimizing CSS as a tertiary goal, and speeding up CSS does not sacrifice other things if done properly.
>Utterly arbitrary. Use as many as you need to get whatever result you’re after. You’re the designer, you know what’s appropriate, and it has little to no impact on performance.
The issue here is that people who use font-size too much are likely simply not appreciating the cascade. That can be said for numerous other properties like float, font-family, padding, and margins.
That all being said, CSS Lint is extraordinarily opinionated. How could it be anything else? If you're looking for a syntax lint, check out W3C's Unicorn. If you're looking to discover a new philosophy for writing reusable, extendable, and optimized CSS, make sure you understand why exactly CSS Lint is throwing you a warning/error and take steps to improve your styles.
Irrespective of opinions on CSSLint, I'm not a fan of this kind of blog post. Doesn't do anything constructive. I didn't see any evidence of an attempt to engage with Nicole and Nicholas or raise concerns at the GitHub repo. That's a shame.
As the name implies, perlcritic can be fairly opinionated, but it has flags and a config file to handle what aspects you wish to criticise. (Quite a few of the 'Perl Best Practices' aren't, anymore, and just add noise to the output.)
Having an extensible plugin architecture for additional tests is also nice.
"And lastly: Performance is a browser level issue, it is not something for HTML/CSS authors to fix or work around. As long as we are authoring valid and sensible HTML and CSS, we should not need to resort to such ridiculous rules simply to enhance the speed at which a given page renders."
If you think that its okay to pass the buck on performance then the author is completely right. On the other hand, if you are looking for ways to write performance oriented code, because you want your pages to be faster, large company or not, then CSS Lint is a great starting place. No one said it was the last word.
UPDATE: I posted a longer thought here http://alexkessinger.net/2011/07/11/a-quick-rebuttle-for-css...
The HTML/CSS hasn't been updated in that time, except to stop enforcing the XHTML Strict Mime type. I'm aware of how poorly the site reflects my skills and how out of date it is. But, at least it works accessibly - if a dodgy glyph on a browser that didn't exist when it was built is the only issue, I'll roll with that.
Fix the problem by specifying the charset in your HTML markup.
I think this gives a clue on how clueless the author is.