
CSS Lint - nephics
http://csslint.net/
======
telemachos
The About[1] page, which explains the linter's rules, should be more
prominently linked I think.

I am very much an amateur at CSS. I know the basic rules (I hope), but I'm
definitely not a designer or an expert. After running some CSS through the
linter, though, and reading the About page, I have a few questions.

First: Why are IDs bad? The About page says:

>> _Don't use IDs in selectors

IDs shouldn't be used in selectors because these rules are too tightly coupled
with the HTML and have no possibility of reuse. It's much preferred to use
classes in selectors and then apply a class to an element in the page._

I don't quite follow. Isn't the whole point of an ID that it is like a class,
but unique? Why exactly would it be better to change all ids to classes with
only one member? (I don't even see how that would be different, except for
making it less obvious to me that they're unique.) _Edit_ : the context about
OOCSS which Jacobr mentions below helps explain this.

Second: Why is it so important that heading styles be declared in exactly one
spot. Again, the About page:

>> _Heading styles should only be defined once

Heading elements (h1-h6) should have exactly one rule on a site. CSS Lint
warns if it finds more than one._

I ran into this because I had one ruleset for h1, h2, h3, etc. to make _all_
the headings use the same font and color, but then I had distinct blocks for
settings that I wanted to be different. (Example, I wanted the h1 to be larger
and have a different bottom margin from h2 or h3. And so on.) I could easily
duplicate things so that each set of rules was in exactly one block, but that
would make the stylesheet less DRY.

(Edit - putting my cards on the table, here's the CSS I checked:
<http://ithaca.arpinum.org/css/screen.css>. I definitely don't doubt it could
be improved.)

[1] <http://csslint.net/about.html>

~~~
rimantas
Don't pay attention to that tool. Nicole has her own and peculiar view on CSS
and many rules in CSS Lint make very little sense.

There is nothing wrong with .foo.bar. There are problems with outdated
versions of IE, should that stop you?

There is nothing wrong with ID selectors.

There is nothing wrong with having display:inline on the floated element. No
harm done, fixes double margin bug in IE6 if you need that.

It is ok to have many rules for heading no matter that CSS Lint says.

It is ok to have width, padding and borders defined. I do that all the time
and surprise surprise, result is just as I intended. I am not sure if CSS Lint
knows anything about box-sizing rule.

Etc., etc.

Unit-less zeroes, no empty rules do make sense, but I guess decent CSS
compressor would take care of those.

~~~
podperson
Agreed -- almost all its complaints about the first css file I passed it were
"don't use id selectors".

I suspect some of the complaints are valid, but simply saying "broken box
model" doesn't explain why.

~~~
pbhjpbhj
Ditto. Funnily enough you also get some rules that tell you to use id
selectors:

    
    
        Overqualified Elements	Element (a#galleryLink) is overqualified, just use #galleryLink without element name.
        a#galleryLink {
    

This was given as a warning, but it's spot on too -
<https://developer.mozilla.org/en/Writing_Efficient_CSS> for example.

~~~
podperson
I think it's actually saying a#foo is worse than #foo (assuming you're not
reusing #foo in which case, conceptually, shouldn't it be a.foo?).

Indeed, I'd argue it ought to say that you EITHER ought to use a.foo or #foo
depending on what you're doing in the page.

I'm not an efficiency nut, but it's quite possible #foo runs faster than .foo
and this might be important to you, even if giving multiple things the same ID
makes you feel dirty.

------
spc476
Curious. Running csslint.net's CSS through itself resulted in 65 warnings. I
would expect them to use their own tool on their own code.

~~~
pbhjpbhj
They possibly did - a warning is not an error.

The tool flags these issues for the [OO]CSS writer to attend to. If I say
"look out walking on that floor it's wet" that doesn't mean you can't choose
to walk on the floor nor even that I'm telling you not to.

------
benologist
The rules are too frivolous and personal-standards flavored, it's difficult to
care enough to look for anything _actually_ wrong amongst the ton of "I don't
do it like this" warnings.

------
kenjackson
_Using float for layout isn't a great idea, but sometimes you have to. 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._

Why is using floats bad, and what are the abstractions one would use in place
of floats? Tables? Or grids?

~~~
pygy_
I don't know either.

I've posted a bug report demanding a clarification of the documentation on
that point.

<https://github.com/stubbornella/csslint/issues/26>

~~~
mark_story
Demanding justification for things a tool you got for free, is a bit
ungrateful. Why not 'request' or 'ask', you might get a better answer.
Demanding things from open source is a pointless venture.

~~~
tiddchristopher
The person you replied to might not be a native English speaker. Demand shares
a common ancestry with the verb "to ask" in some languages. Take French's
"demander" and you might see why someone could use "demand" in a way that
sounds confrontational in English but quite normal in another language.

------
calloc

        Heading (h1) should not be qualified.
    

Yes it should, especially if you are using HTML 5 and are using different
heading sizes for different parts of your site... Otherwise an h1 in a header
(tag) would look the same size as a h1 in an article (tag).

~~~
nirvdrum
I could be mistaken, but I think the idea is you only have one h1 per page. If
you use an h1 in different contexts on different pages, the rules for those
pages should probably be in different stylesheets as well, obviating the need
to qualify them.

~~~
calloc
In HTML 5 you can use the h1 element multiple times. For example, lets say you
are writing an article

    
    
      article
        h1
        h2
    

That is perfectly valid, now lets say you have an header that gets added
before each article that contains some information such as author, time
created/published

    
    
      header
        timedate
        h1 
          Article Title
        author
      article
        h1
        h2
    

This is valid HTML 5.

~~~
treyp
In HTML5, not only is it valid, but doing otherwise would break the document
outline.

------
richard2me
I'm entering the CSS found on major websites. The following is a rough feel
for how many errors and warnings csslint is detecting.

this page = 1 errors and 2 warnings

craigslist.css = 4 errors and 340 warnings

facebook's css files' = 0 errors and 140 warnings

google home page: 0 errors and 0 warnings

ebay = 0 errors and 64 warnings

Are these results meaningful? I don't know. Thoughts?

~~~
sbierwagen
Don't forget the 65 warnings thrown... on CSS Lint's CSS code.

I'm not going to say it's useless, but it certainly isn't as good as a real
CSS validator.

------
ars
Well, that was impressive. 82 warnings, and every single one was wrong. This
is not a useful tool.

------
tjogin
The biggest problem with CSS today is that the source code _is_ the product.
One possible solution to this problem is to use SASS (<http://sass-lang.com>),
thereby separating the concerns of the quality, structure, reusability (etc)
of code from the aspect of browser rendering efficiency.

Many of the aspects of CSS Nicole is trying to improve with OOCSS/CSSLint
simply vanishes when you use SASS (though some still stand). Some of the
points as they pertain to CSSLint: <https://github.com/stubbornella/csslint>

Take for instance the issue of reuseability. Nicole's solution to that is less
CSS selector specificity, to not use IDs, and to sprinkle containers with
several modular CSS-classes. By using SASS functions, mixins and extends you
can achieve that _without_ doing either of those things.

I much prefer using SASS to manage my source code and the related concerns,
without resorting to these kinds of sacrifices.

~~~
billybob
I know some of the things that SASS gets you, but I'm curious: how DRY and
light is your generated CSS?

Anecdotally, the designer where I work uses SASS, but in our last iteration of
our web app, his compiled stylesheet was something like 10,000 lines.

~~~
tjogin
It depends on how you use SASS. Used correctly, with @extend rather than
@include for big swatches of styles that reoccur in multiple places, it will
be DRY and light.

Your designer colleague probably didn't have a sufficient understanding of the
difference between @extend and @include. It's not hard though, a few tests
using the different methods and analyzing the results should be enough to
understand when to use each.

It is utterly impossible to generate worse CSS with SASS than by just writing
CSS directly, as SASS does not _deprive_ you of any CSS feature. SASS provides
you with a bigger and more capable toolbox, but won't stop you from using the
wrong tool in any given situation.

------
igorgue
I don't see any reference to a CSS standard, for example pylint follows PEP
0008. This looks like the experience of a developer.

------
rbxbx
I know it's just picking nit, but seeing as that's basically the entire point
of CSS Lint...
[https://github.com/stubbornella/csslint/blob/master/lib/pars...](https://github.com/stubbornella/csslint/blob/master/lib/parserlib.js)
The entire library is in a single ~4700 line file with ~80 line long
functions... Ugh.

~~~
thezilch
The included parselib is actually sourced/built from the following:
<https://github.com/nzakas/parser-lib/>

As well, the functions and built lib are chock-full of comments, which any
decent IDE should be able to fold away.

Note: I paid no mind to how integrated libs are made as dependents of CSS Lint
project. Then again, I have a feeling javascript projects are only more
recently warming up to the idea and being built around the idea of
dependencies, cross-party builds, etc.

------
mscarborough
During their presentation at Velocity today, they made the github project
public:

<https://github.com/stubbornella/csslint>

------
alexnime
Linting (where you're going wrong) without explaining why (you're going wrong)
is one of the most pointless exercises ever.

Maybe too much attention put on aesthetics, less on code (nice start though)

------
spjwebster
Owing to the lack of options, this is only useful for linting CSS written by
the authors or anyone who happens to agree with their opinions on what
constitutes good CSS.

Crockford may be an opinionated cantankerous old goat _, but at least he gives
you options to dial down some of the crazy he's baked into JSLint.

_ * He's also awesome, but anyone who's worked at Yahoo! or glanced at the
JSLint Issues list or Pull Request queue can attest that he has strong
opinions. _

~~~
timdown
You can't remove all the craziness in JSLint. The warnings about using ==
instead of === and not having your var statements at the top of the function,
for example.

------
georgefox
_width: x; padding: 0_ produces "Broken box model: using width with padding."
Same for height. Isn't it exactly the opposite of using padding?

------
spoold
"CSS lint found 0 errors and 0 warnings. How can you fix it? See the details
below." Um, right. Whatever.

------
Skywing
The rules that this tool follows appear to be based on the creator's own
personal opinions. Personally, I'd advise against at least several of the
rules.

------
alexwallace
Reading "JavaScript: The Good Parts" is an excellent crash course in writing
decent JS but JSLint regularly ensures that you stay on the right track.
Reading through CSSLint's guidelines, I agree with the bulk of it and am
excited to have CSSLint keep my stylesheets on the right track. Hopefully an
analogous TextMate "run csslint on save" bundle is right around the corner!

------
gue5t
It seems like this is useful in generating critiques of CSS for web pages in
development, but user-style CSS (the primary sort I work with) has a different
set of priorities that lead to selectors that seem to be considered poor style
and warned against accordingly. It did point out several valid points I hadn't
noticed and should fix, though.

------
bromagosa
I like it, but it'd be really nice if it linked each rule to some kind of
explanation on why is the rule right.

------
dw0rm
I've been using paddings and left and right margins on inline elements and
this tool tells me I can't.

------
BasDirks
_"Don't use IDs in selectors"_.

What?

I need my CSS fast, Ferrari fast.

I don't need toddlers to be able to have a mental model of all my style rules.

~~~
pornel
I don't agree with this suggestion either, but I don't think IDs have
significant speed advantage:

• browsers support duplicate IDs already (try `<p id=foo></p><p id=foo></p>`
and you'll find that `#foo` styles both)

• both IDs and classes can be preprocessed and looked up using hash tables or
similar

<https://developer.mozilla.org/en/Writing_Efficient_CSS> — suggests that Gecko
optimizes class lookup as well

------
Pistos2
An obvious next feature is to allow submission of a URL, and it parses out the
linked stylesheets and runs itself on those. i.e. lint my site

------
Hovertruck
Hah, I was just sitting in the talk at Velocity where they announced and open-
sourced this.

------
piranha
Eh, command line output is a bit weird. Still, trying to get it work in
Emacs... :)

------
rorrr
It's useless, too many stupid or plain WTF rules, like

1) "Don't use IDs in selectors"

2) Most "Overqualified Elements"

3) "Broken box model: using height with padding"

~~~
HRoark
The "Don't use IDs in selectors" was really random.

