Session slides from Future Insights Live, Vegas 2015: https://futureinsightslive.com/las-vegas-2015/ In this session we'll 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.

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