CSS Lint is harmful(mattwilcox.net)
mattwilcox.net
CSS Lint is harmful
http://mattwilcox.net/archive/entry/id/1054/
12 comments
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.
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.
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.
[deleted](1)
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.
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.
>> 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...
More straightforward to use the W3C's CSS validator for that: http://jigsaw.w3.org/css-validator/#validate_by_uri+with_opt...
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.
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 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:
And I can write perfectly maintainable code with lots of floats if I have them sized and cleared properly.
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}
And I can write perfectly maintainable code with lots of floats if I have them sized and cleared properly.
Having too many floats is the canary in the coal mine. It's there to help you have a sense of how well you are structuring your CSS.
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.".
Really, honestly, what does this even mean?
Really, honestly, what does this even mean?
"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 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.
My take is that the sole purpose for CSSLint existence is to promote OOCSS.
Possibly so. Though if that is the case, it could be made more obvious, because OOCSS is mentioned absolutely nowhere on CSSLint.net.
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.
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).
Umm... that's what all 19 of those checkboxes on CSSLint.net are for.
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.
Disclaimer: I am maintainer of JSHint, a fork of JSLint.
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.
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.
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.
+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.
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.
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.
>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.
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.
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.
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.
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.
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...
"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 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.
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.
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.
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.
Fix the problem by specifying the charset in your HTML markup.
Not just "considered" harmful but "is" harmful!
> ID’s are extremely useful and you absolutely should use them.
I think this gives a clue on how clueless the author is.
I think this gives a clue on how clueless the author is.
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.