CSS Lint updated to 0.5.0
After a slight delay to figure out some UI changes, the 0.5.0 release of CSS Lint has now made it to csslint.net. As with previous releases, this release saw a mixture of bug fixes and new features. The biggest change you’ll notice on the web site is that rules are now categorized based on how they help your code. We received a lot of feedback that you weren’t sure why some rules were there. We hope that categorizing the rules will help clear up some of that confusion (there’s more documentation coming, we promise!). There were also a lot of changes under the hood, here are the highlights:
- cssguru pointed out that the
!importantrule didn’t tell you how the target usage count. That has been addressed. - Eric created a one-line-per-file output format that matches JSHint’s output format.
- Senthil discovered a problem with the Rhino CSS Lint CLI where directories were not being read. The CLI has now been fixed and directories can be recursively read once again.
- The CSS parser now correctly supports CSS keyframe syntax and CSS escaping.
- cssguru also argued that having too many important declarations should not be an error. After some discussion, we agreed, and this is now a warning.
- mahonnaise suggested that a rule to detect the universal selector would be a good addition to the tool. We agreed, and 0.5.0 now warns when using the universal selector as the key selector.
- Oli found a bug in the box model rule where valid box model settings are flagged as problematic. This issue has been resolved.
- I added a rule that checks for known CSS properties and warns if the property is unknown. Vendor-prefixed properties are considered exceptions to this rule.
- Nicole added a rule that warns when a large negative
text-indentis used without first setting thedirectiontoltr.
Of course, there are other miscellaneous fixes and tweaks that have gone into this release. If you’re using CSS Lint for Node.js, you can update by typing:
npm update csslintAnd please keep sending in your bugs and suggestions over on GitHub as well as asking questions on the mailing list. Your feedback has been invaluable in making this tool even better.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.
4 Comments
i can’t understand the reason why the warns is nesscesary when a large negative text-indent is used without first setting the direction to ltr. any detailed information or explaining… thanks
xiaohao on August 18th, 2011 at 7:16 pm
Great update Nicholas! The categories were definitely needed and had never considered LTR direction for the negative text-indent trick.
Small usability request: could you please cookie/localstorage the checkbox states as a way to save user preferences?
Kevin Sweeney on August 19th, 2011 at 7:55 am
@Kevin – can you please file an issue at the GitHub repo? That sounds like a great enhancement.
Nicholas C. Zakas on August 19th, 2011 at 11:55 am
>i can’t understand the reason why the warns is nesscesary when a large negative text-indent
>is used without first setting the direction to ltr.
Even with a large text-indent it won’t necessarily leave the container. E.g. if you set overflow to auto, it won’t ever leave the container (if your document is rtl for some reason). If you want to ensure that it goes outside the container, it needs to be in the opposite direction of the writing direction.
So, you either need negative text-indent + ltr or positive text-indent + rtl. It’s a robustness (or principle of least astonishment) thing.
Jos Hirth on August 19th, 2011 at 1:50 pm
Comments are automatically closed after 14 days.