Lint Policy

##Introduction

CSS Lint is an emerging testing platform for style sheets. A run through Lint should be part of [Testing] prior to trunk commits. This document explains the Hawidu CSS project's stance on the CSS Lint rules on a three-grade scale: required, recommended, ignore.

##Rules Explanatory documentation can be found on CSS Lint's About Page.

##Parsing errors should be fixed Lint's parser is actually less strict than the W3C Validator, so any errors should be sorted before getting to Lint. Required

##Don't use adjoining classes While adjoining classes don't work in IE6-, they do work in all browsers Hawidu CSS supports. Use them when they're useful. Ignore

##Remove empty rules Empty rules can lead to bloat, but can be useful when part of a good nesting scheme. For absolute top compression/performance, empty rules should be commented-out or removed in production. Ignore

##Use correct properties for a display Required

##Don't use too many floats Making classes, especially non-semantic ones, to handle floats is no better than declaring floats multiple times. This rule is arbitrary and based on the tastes of Lint's authors. The same could be said for any property (don't use too many white-spaces!). Rather than class-itis and/or semantically-empty grid systems, use floats as appropriate. Ignore

##Don't use too many web fonts Hawidu CSS isn't set to include web fonts in core until at least 2.0. Paste-ins and snippets are welcome to include web fonts, to be included in end user sheets per their discretion. This isn't really a CSS issue, as the main concerns are bandwidth and aesthetic, rather than syntax and cascade efficiency. Ignore

##Don't use too many font-size declarations An arbitrary rule with an arbitrary criterion. At a certain point "Don't use too many" should apply to all properties. Taking a page from oocss, resets must not count toward Lint results; so since Hawidu's reset is rolled into its core, the number of font-size decs we use is wholly appropriate. Ignore

##Don't use IDs in selectors CSS applied to IDs should be in JavaScript, where selector performance is more of a concern. Required

##Don't qualify headings We "qualify" headings by giving them link styles. This is so headers appear the same or similar whether or not they're links, with subtle differences if they've visited, hovered, focused, or active. If we want headers to look different in different parts of the page in core, that's also our prerogative. Ignore

##Heading styles should only be defined once A stupid rule that the rule's creators ignore with reckless abandon (by using/recommending YUI reset). Nonetheless, we're going to try it for the 1.0 release out of spite. Required ? Ignore

##Zero values don't need units Syntax rules. Required

##Vendor prefixed properties should also have the standard Required

##CSS gradients require all browser prefixes Arbitrary. Why gradients and not others? When should this rule change? Rather than rely on CSS Lint, rely on semi-graded browser support. Ignore

##Avoid selectors that look like regular expressions These selectors are slow, but are the best tool in the box for styles based on the end of filenames, like our core link icon styles. Ignore

##Beware of broken box models Until we revamp the core layout to use CSS3 fanciness, this is probably a good idea. Recommended

##Don't use @import

All of our CSS is in one file. Required

##Don't use !important

I'd downgrade this to "Avoid using !important", as there are circumstances where it could be required/useful. Recommended

##Include all compatible vendor prefixes

Opera isn't really necessary, and it's important to stay on top of which browsers no longer require prefixes at our semi-graded support level. There are also circumstances where we might use prefixes to target particular engines, though this is tantamount to hacking. Recommended

##Avoid duplicate properties

Use them when needed/intentional, avoid them when redundant/unintentional. Recommended