Hey Nicholas (and Nicole)!

I think this is a really cool initiative and am happy to see the two of you starting it. My one criticism at this point is that there are no options (that I saw) to disable certain warnings. As an example, I for one, don’t think it’s horrible to use IDs in your selectors (if done correctly). Another area of concern would be for users who copy CSS resets into the mix—which will obviously be throwing a lot of duplication warnings.

Keep it up!

Kevin Sweeney on June 15th, 2011 at 2:12 pm

@Kevin – The ability to turn on/off rules will be coming, we just didn’t have enough time to get it into the interfaces before our talk. The API actually already supports filtering the rules, we just need to expose it.

Nicholas C. Zakas on June 15th, 2011 at 2:47 pm

Hi Nicholas (and Nicole),

A couple of things: I get parsing errors on comments like /*/*/.
Also, it warns me about margin and padding left on inline elements, even though this is perfectly valid (they do apply on inline elements).
It would be a different story if it was top/bottom margin of padding. Which makes me think that it would be very cool if the tool was also giving warning not only according to explicit declarations but also regarding type. For example, it would be great if the following would throw a warning:

span {margin: 20px 0;}

Keep up the great work!

Thierry Koblentz on June 15th, 2011 at 3:59 pm

@Thierry – Thanks, there are definitely some parser issues we’re working through. The points you bring up are all good and I think are covered by the issues we have filed at the GitHub repo right now. If not, please feel free to add more issues. This is definitely version 1.0.

Nicholas C. Zakas on June 15th, 2011 at 4:54 pm

(Sorry for another comment!)

Looking through the “About” page, it appears as though CSSLint sits halfway between standardisation and minification. For example, removing entirely empty rules should, in my opinion, occur during minification. Often, when I’m developing, I’ll fill the CSS with empty rules, and then use these as hooks for styling in Firebug.

I also wonder whether the hard-coded numbers (such as 10 floats max) should relate in some way to the size of the CSS file or the number of rules in it. Whilst these numbers make sense for websites, I’m not so sure about webapps — often, the CSS for a webapp will be two to twenty times the size of that for a website!

I think that this website-over-webapp motif is also in rules such as “Don’t qualify headings”, “Heading styles should only be defined once”. I’m looking forward to toggleable settings!

barryvan on June 15th, 2011 at 5:35 pm

Great tool. Especially eye-opening to see just how disgusting jQuery UI CSS is.

It should probably check for unique vendor prefixes like -webkit-appearance and -ms-interpolation-mode and not think that I should add the vendorless of those.

It’s also giving me a parse error if using an @page inside a media query. Here from the boilerplate print styles:

@media print {
* { background: transparent !important; color: #444 !important; text-shadow: none !important; }
a, a:visited { color: #444 !important; text-decoration: underline; }
a:after { content: ” (” attr(href) “)”; }
abbr:after { content: ” (” attr(title) “)”; }
.ir a:after { content: “”; } /* Don’t show links for images */
pre, blockquote { border: 1px solid #999; page-break-inside: avoid; }
thead { display: table-header-group; } /* css-discuss.incutio.com/wiki/Printing_Tables */
tr, img { page-break-inside: avoid; }
@page { margin: 0.5cm; }
p, h2, h3 { orphans: 3; widows: 3; }
h2, h3{ page-break-after: avoid; }
}

Erik K Veland on June 15th, 2011 at 9:16 pm

wait, why not use ID selectors? they’re extremely useful and i thought they were considered one of the quickest & most efficient* types of selector for css rules. i read on in the css-lint documentation that you suggest using classes, but sometimes pages have a fair amount of unique elements that require styling.

also, you may then end up with a fair amount of “one-off” classes, and then you’re still sorta tied to the HTML and—in my opinion—less semantically sound, as a class is meant for more general application.

* http://css-tricks.com/efficiently-rendering-css/

Dominick on June 15th, 2011 at 10:44 pm

[...] erst sinnvoll nutzbar, wenn ich einzelne Regeln von der Überprüfung ausschliessen kann. Zakas fasst die Regeln kurz zusammen (zur besseren Orientierung habe ich die ungeordnete in eine geordnete Liste [...]

CSSLint – ein Ansatz zum CSS-Qualitätscheck « F-LOG-GE on June 15th, 2011 at 11:24 pm

Great tool, I’ll definitely be using this.

A small detail that may add to the UI friendliness of the results table would be adding cursor: pointer to its headers. That way, it’s more obvious that those parts are clickable

Kristiaan Van den Eynde on June 16th, 2011 at 4:27 am

I notice the parser doesn’t handle + very well. For example h2 + h6 it parses as a change to h2 not a chnage to h6.

Other than that bloody good work!

John Milmine on June 16th, 2011 at 2:25 pm

@everyone – Few things. First, we realize not everyone will agree with all of the rules. All we can say is that in our experience working on many large-scale web sites, these rules help dramatically cut down on errors and can improve performance. We believe in these rules so we won’t be removing them. However, as I’ve said before, we will be allowing you to selectively turn on or off rules very soon (working on it now), so you can feel free to just turn off any one that you don’t agree with.

As for style.css – yes, we know. That was intentional. There are a whole bunch of other little easter eggs on the site as well.

And please report parser errors at http://github.com/nzakas/parser-lib rather than leaving them in comments. (CSS Lint bugs may be filed at http://github.com/stubbornella/csslint)

Nicholas C. Zakas on June 16th, 2011 at 5:05 pm

I don’t agree with warning about using 0 with unit if it is in compact form, and other lengths are not zero, e.g.: padding: 4px 0px 2px 0px;

Another issue is passing entered CSS in GET request… which doesn’t work for larger files (argument too long). It would be better to implement it via POST. It would be nice to allow options to point to an URL, and to upload file, like with W3C HTML Validator… though probably not all are possible beause of performance reasons.

Jakub Nar?bski on June 17th, 2011 at 2:22 am

[...] the original here: Introducing CSS Lint | NCZOnline Share and [...]

xhtml css templates – Introducing CSS Lint | NCZOnline | XHTML CSS - Style sheet and html programming tutorial and guides on June 18th, 2011 at 10:13 am

How’d you come up with 10 as the limit for floats etc? It seems very arbitrary. Maybe it would be better in comparison to the length of the CSS file – a file that contains styles for a website that employs a few different variations on its layout and is a mile long might have more floats, font sizes etc than a site with just 20 rules.

Ben on June 20th, 2011 at 8:24 am

First I must say well done for trying to make our lives easier

However just to confirm what Thierry said above you need to remove the warning for horizontal padding/margins on inline elements as they are perfectly valid and extremely useful.

In your documentation (http://csslint.net/about.html) you also state this:

“display: inline should not use width, height, margin (and all variants), padding (and all variants), or float.”

Again you mention padding and margin but it is only vertical margins that have no effect on inline elements. Vertical padding can be applied to inline elements but will have no effect on the flow of the surrounding content which means in some cases that it can be used for good effect. The warning should really only be for vertical margins on inline elements,

Finally you mention don’t use float and inline together and while that should be true the practical effect is that it will immediately cripple 99% of the sites out there in IE6 as display:inline added to float is the fix for the double margin float bug. I know IE6 is low usage these days but it’s such a simple fix.

Otherwise well done for the hard work that obviously went into this.

Paul O'Brien on June 21st, 2011 at 2:05 am

@about the ID (or hash) selector argument,

I’ve ran into a problem where I simply declared a font-color to the container,

… something like …
#content a {
color: #3333FF;
}

Then, suddenly, some links in the design (psds), required me to change their link colors, but in order to do that, I will need a higher cascade level to overwrite ‘#content a’ declaration.

… it ended like this …
#content .page-name a {
color: #FFCC33;
}

So, whenever we will change a different element (or tag) link colors, when will always be needing the ‘#content’ followed by the targeted class or element to overwrite the ‘#content a’ declaration, which in the end, became a hassle. And what actually solved the problem was to simply change ‘#content’ to ‘.content’ (now it’s class).

… So if something like this happens …
.content a {
color: #3333FF;
}

… This could easily be overwritten by …
.page-name a {
color: #FFCC33;
}

Since they are equal, except that ‘page-name a’ was declared last, so it will take effect than the previous one.

Since they said that the evaluation is based on ‘experience’, we need to somehow consider their suggestions seriously. My problem was just on a mini-site, but compare that to a larger project, that could bring more problems than mine (little project).

E-Jelome on June 24th, 2011 at 1:23 pm