Style rules like whitespace and indentation + lowercase

[itpastorn]

CSS Lint would be an even more awesome tool for me as a teacher if it would require my students to use proper style rules, especially for white space and indentation. (Note that github won't give me monospace fonts in pre-block, so it's hard to show exactly what I mean.

Rules I like (starting point of conversation):

1. Always indent blocks (using 4 spaces). (Single property rules may be allowed on one line.)
2. Align vendor prefixed properties on the colon - ignore rule 1 for these.
3. Alternate style: Align all properties on the colon...)
4. Require a trailing space after comma - in properties as well as values like RGB(A) and HSL(A)
5. Require a space between each token in child selector rules. Disallowing .foo>span, requiring .foo > span.
6. Require a space after the colon in properties. (Exactly one)
7. Disallow a space before the colon.
8. Require a semi-colon on the last rule in each block. (It's soo easy to forget this when adding another property.)
9. Require all element selectors to be lower case, all property names to be lower case and all property values to be lower case. (XML users may turn this off.)

[shinuza]

From my understanding the API CSSLint exposes is too high level for what you want to do. I don't think you have access to AST/parser features so I guess it would be difficult for CSSLint to provide control on the rules you mention.

Also, CSSLint helps you writing rules and properties that will scale, not writing CSS that match a set of coding rules (which are your own in this case).

[hpbuniat]

i think tools like e.g. php_codesniffer are more suitable for this purpose. it already allows checking the css code-style against customizable and expendable rulesets.

[itpastorn]

Isn't it a bit too early to tell what CSS Lint ever will be able to do? If someone will write a patch to provide whitespace checking, using reasonable and customizable riles, should it not be accepted? I think so!

[shinuza]

Even if CSSLint provide this, you'd write these rules yourself, because unlike Python, the CSS recommendation doesn't provide a Style Guide.
It's a lot of changes, and the resulting API - it's too low-level - will be quite annoying to use, well at least that's my point of view.

[nzakas]

I can tell you pretty easily what it can and can't do based on the information available from the parser.

Is it possible to determine indentation? Yes.
Is it possible to deal enforce whitespace? No. The parser skips over whitespace and only returns tokens.

You can kind of figure out if things have spaces before or after them by looking at the line and column numbers for various tokens.

The best way to figure it out is really to just try and write some rules yourself. :)

[hpbuniat]

That's my point exactly. As shinuza mentioned, there is no real style-guide which most people agree to. In fact i like your 'rules' as those provide 'readable' css, but if you're looking at perfomance guidelines, best-practices, etc. the quintessence is space at the expense of read- and maintainability.

[LeeKowalkowski]

I'm not convinced either, if you adopt & insist on such rules, you don't need a validator, you need a formatter, sorry. I don't think you need a commentary of every breach of your code conventions if they can be automatically fixed in a single click.

[itpastorn]

I think you're missing my introductory remark: "as a teacher". I am perfectly aware that there are many different style guides and that some authors do their minification manually. Any rules in this regard should therefore probably be turned off as a default. But as a teacher it would be simply awesome to have this feature as well.

If parts of what i am proposing is indeed possible (which nzakas is hinting) and won't have any discernible negative effects on users not taking advantage of the feature, why not?

[LeeKowalkowski]

I did miss your remark. (Well, by the time I'd finished reading all the comments, I'd forgotten about that)

But as a student, I'd rather learn about the formatting tools. The number of options required for code formatting preferences are just too many for a validator. Thinking about JSLint, the option is the author's way or nothing, so for most people, nothing it is.

Just for contrast, these are the differences between your rules and what I do:

1. Tab is for indentation, the visible size of a tab is user preference (I usually use 2). Although I indent my CSS, I'm not sure why I even do it, because there's only ever 1 level. Although I thought some ideas in http://css-tricks.com/different-ways-to-format-css/ were novel, particularly "Multi-line Format with Indenting".
2. Never align anything on the colons, looks pretty but I find it impractical.
3. No space after the colon.
4. Comma-separated lists of selectors have a new line after the comma.
5. Braces go on their own line.

Not much difference, but if you look at http://css-tricks.com/different-ways-to-format-css/ there are many different styles.

I'd love a decent formatter. I think lessons on what is readable should be separate from lessons on what is valid. If you had a formatter, you can use a diff tool to teach if you wanted to. My personal opinion is this feature (whilst awesome) would complicate the validator.

[nzakas]

Since styling guidelines are pretty personal, I'm not sure it would be a good fit for CSS Lint. This probably falls under the category of things that I hope people will write as extensions to CSS Lint but not necessarily as a core piece. If you happen to create one that does this sort of style checking, I would certainly love to take a look.