
CSS Lint is harmful - robin_reala
http://mattwilcox.net/archive/entry/id/1054/
======
tjogin
I agree with the article, almost to the letter.

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.

~~~
andrewl-hn
Is there something wrong with OOCSS? I remeber a number of great talks Nicole
gave about it a while back and I can't recall if there were any objections to
it at the time.

~~~
pygy_
It is one effective CSS method, not the only CSS methododolgy.

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_.

------
msy
JSLint is opinionated but it's hard to argue that anything in there isn't a
good idea, even if it isn't necessary. CSSLint is just opinionated.

~~~
damncabbage
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.

~~~
bobfunk
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.

~~~
pornel
I don't think maintenance difficulties are related to number of float
declarations.

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.

------
Skywing
No offense to the creator of the css lint website, but I had no idea that
anyone actually took the site seriously. When I first read the rules that it
uses I thought it was a sarcastic trolling website. From what I recall, many
of the comments about it in its original thread on HN seemed to echo the same
sentiment.

------
HamletDRC3
I am the main author for a static analysis tool for a dynamic language on the
JVM. My tool also has many rules that could be considered controversial, some
rules that conflict with each other, and (I hope) many rules that are
genuinely useful. Our message has always been: configure the ruleset based on
the coding guidelines that you want for your project. There is no one ruleset
to rule them all.

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.

~~~
kitsaws
+1 for this comment For all static (heck, even runtime) analysis tools, I
would rather have more rules than less - and disable the ones I don't
like/want/agree with. I wrote the code, I set the standard for rules, it's
that simple.

------
BasDirks
Nicole is very competent, but CSSLint is crap. I agree there _is_ a problem
with CSS, but solutions will need to be far less dogmatic.

------
huckfinnaafb
The author claims OOCSS is a great philosophy when writing CSS, but then goes
on to complain about a tool that is specifically written with OOCSS in mind.
It would be a much simpler thing to write "CSS Lint checks for good OOCSS
habits, but can't be trusted to verify non-OOCSS, so be wary."

> _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.

------
necolas
Some of the "advice" in CSSLint _warnings_ isn't just about performance and
smaller CSS files, it's about writing maintainable CSS and being able to
produce reusable classes or components for the development team. Depending on
the project, that may or may not be a concern.

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.

------
shabble
Sounds like what'd be much more useful is something like perlcritic:
<http://perlcritic.com/> rather than a -lint tool.

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.

------
voidfiles
This is the operative quote from the whole article.

"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...](http://alexkessinger.net/2011/07/11/a-quick-rebuttle-for-css-lint/)

------
btilly
The author claims that you don't need to pay attention to advice about
portability because it isn't that hard. And then makes the article look bad
from my OS X notebook because he couldn't use single quote characters in a
font that that, you know, actually renders.

~~~
MattWilcox
Hi, I'm Matt. I can only apologise for the site and your poor experience using
it. The design/html/css is about 5 years old, and the core of the site is
hand-coded from the ground up (WordPress didn't exist when I built it some 9
years ago).

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.

~~~
tjogin
The problem is that you haven't specified a charset, so the browser just uses
its default setting, sometimes causing problems when the default is anything
other than ISO Latin-1.

Fix the problem by specifying the charset in your HTML markup.

------
PaulHoule
Not just "considered" harmful but "is" harmful!

------
voidr
> ID’s are extremely useful and you absolutely should use them.

I think this gives a clue on how clueless the author is.

