CSS Audits: Take back control of your CSS

We dive deep into the nuts and bolts of how to audit your existing CSS. By understanding the reasons for doing it as well as how you can learn, as your auditing, how to keep your CSS lean and mean in the future. You'll leave with tools and ideas for how to do an audit, as well as what to do with the information once you’ve got it. Your audit can even be a springboard to create CSS guidelines and even a style guide.

Transcript

1. CSS Audits @susanjrobertson susanjeanrobertson.com Take back control of your CSS
2. Me Developer @ Writer @ &
3. Old Application, layers https://flic.kr/p/4xVXxH
4. Admitting there is a problem
5. Wrangling for time https://flic.kr/p/8J6XML
6. Cleaning == deleting Remember, you have version control to find things again :)
7. Benefits
8. Consistency
9. Standardize code Decide about the best ways to write code going forward and DOCUMENT IT!
10. Reduce files Elimination of ~200 lines of code
11. Increase performance https://flic.kr/p/FpnZC
12. Familiarize yourself with code base
13. How
14. Inventory
15. Tools
16. CSS Dig http://cssdig.com
17. StyleStats http://www.stylestats.org
18. cssstats.com
19. CSS Lint http://csslint.net
20. Type-o-matic http://type-o-matic.net
21. Grep http://www.cyberciti.biz/faq/howto-use-grep-command-in-linux-unix/
22. CSS Colorguard https://github.com/SlexAxton/css-colorguard
23. Dust-me Selectors https://addons.mozilla.org/en-US/firefox/addon/dust-me-selectors/
24. Visual Inventory http://bradfrost.com/blog/post/interface-inventory/
25. Read through
26. Depth of Applicability https://smacss.com/book/applicability
27. Specificity issues .orderdetail_wrap .dapth_wrap .dapth_data .shopping_cart .checkout_orderdetail_table .item_price_box
28. Review
29. Tighten code How modular is it? Consolidation?
30. Preprocessors Mixins/Extends/Placeholders Nesting Output
31. Consistency
32. Coding Philosophy OOCSS SMACSS BEM
33. Deviations Document why you may stray
34. Recommend
35. Write up Outlines are fine Give reasons Good explanation
36. Explanation of reasons
37. Make a plan
38. Order the recommendations
39. Small pieces that can be done? • Navigation • Blog post • News section
40. If major, are there sections? • Basket and Checkout • Product pages
41. Markup may need to change
42. Style guide or standards?
43. Document your CSS Comments? Spaces or tabs? Empty lines between rule set? Space between property and value? Is nesting OK at all, if so how deep? Break up CSS into one style sheet per module or not? Build process if using a preprocessor? Do you commit and track generated files?
44. Where will docs live? Easily accessible & convenient for entire team Best online, either privately or publicly
45. How will it maintained? • Schedule when to go back to audit & review • Base schedule on the rate of your application changing. • Monthly, Quarterly, Yearly?
46. Time estimate Imagine you could devote time to just this? How long would it take? By section or the entire thing?
47. Hand off or get to work!
48. How was my app better?
49. FiftyThree Type Audit http://www.fiftythree.com/styleguide/typography
50. Cleaned up/better understood https://github.com/Editorially/styleguide
51. Marriott
52. BONUS POINTS for documentation that helps people understand you code base quickly.
53. Thank you A note of thanks to Ethan Marcotte, Rob Brackett, Jason Grigsby, Max Fenton and Jonathan Snook for early feedback on this talk. Also, thanks to Flickr users and their creative commons photos. @susanjrobertson susanjeanrobertson.com