Maintainable CSS
•
27 likes•24,715 views
This document discusses how to write maintainable CSS through organizing CSS files according to a design language's components (e.g. layout, color), authoring semantic and portable CSS code using classes and IDs, and documenting CSS code and conventions either through inline comments or generated documentation from comment tags. It emphasizes organizing CSS files by concern rather than by site section, separating IE conditional code into separate files, using a system for declaration order and formatting for readability, and having an effective text editor for working with CSS code.
Report
Share
Maintainable CSS
- 1. maintainable.css Stephen Hay . Fronteers, Amsterdam . 20080911
- 6. #maintainable.css { organizing: yes; authoring: quality; documenting: please; }
- 8. Firebug makes us lazy. We need to know intuitively which file we need.
- 9. Design language as a guide.
- 11. Components of design language: Layout (composition) Color Imagery Typography Form
- 12. Resulting CSS files: layout/form/reset color/imagery type IE (6/7) Print etc. A single file can also be organized into these sections.
- 13. Resulting CSS files: layout.css color.css type.css IE (6/7) Print etc. A single file can also be organized into these sections.
- 14. No section or page-based ! Site sections can be handled within each file.
- 15. Old news? Everybody does it this way? Nope.
- 16. IE code in separate files. Use conditional comments to include these files.
- 17. Pamela Anderson comment <!-- Pamela Anderson -->
- 18. Pamela Anderson comment <!-- Pamela Anderson --> IE conditional comment <!--[if lt IE 7]> (...) <![endif]-->
- 20. authoring.css
- 22. focus .more .here { focus: less-here; }
- 23. Maintainable starts with maintainable . And semantic = maintainable .
- 24. Avoid placing in the markup.
- 25. Frameworks can be a problem. Frameworks are made for ease of development, not for maintainability.
- 26. Frameworks fill with layout code
- 27. Framework classes are often meaningless outside the context of the framework. This demands knowledge of the specific framework, which decreases maintainability.
- 28. The Rule of Portable Meaning ids identify classes classify
- 29. Marking up a web designer <li >Andy Clarke</li>
- 30. Marking up a web designer <li class=quot;designerquot; >Andy Clarke</li>
- 31. Marking up a web designer <li class=quot;designerquot; id=quot;andyquot;>Andy Clarke</li>
- 32. Marking up a web designer <li class=quot;designerquot; id=quot;andyquot;>Andy Clarke</li> This list item has portable meaning. Microformats have portable meaning.
- 33. Use the cascade. Be specific only when necessary. This will simplify your .
- 34. Understand specificity. Helps when working with someone else’s code.
- 35. a b c d = specificity
- 36. inline IDs classes/attributes elements (pseudo−)
- 37. li#andy 1element = 0101 0inline 1ID 0classes
- 38. li.designer 1element = 0011 0inline 0IDs 1class
- 39. Otherwise, read Andy Clarke’s Specificity Wars.
- 40. Is it really that !important? Avoid !important whenever possible.
- 41. Use a system for declaration order and formatting.
- 42. Declaration order Alphabetical order div.news { border: 1px solid #ccc; color: #878787; line-height: 1.2; margin: .8em; padding: .2em; }
- 43. Declaration order Alphabetical order Layout first div.news { div.news { border: 1px solid #ccc; margin: .8em; color: #878787; padding: .2em; line-height: 1.2; line-height: 1.2; margin: .8em; border: 1px solid #ccc; padding: .2em; color: #878787; } }
- 44. Declaration order Alphabetical order Layout first div.news { div.news { border: 1px solid #ccc; margin: .8em; color: #878787; padding: .2em; line-height: 1.2; line-height: 1.2; margin: .8em; border: 1px solid #ccc; padding: .2em; color: #878787; } } Necessary? With separate sheets, this is less of a problem.
- 45. Formatting Element tree indentation div.news { (...) } div.news h2 { (...) } div.news h2.just-in { (...) } div.news p { (...) }
- 46. Effective text editing Folding Marks Tags Abbreviations, mapping Decent text editors do these and more.
- 47. Folding gives you the big picture
- 48. Folding gives you the big picture
- 49. Marks for jumping around your code
- 50. Tags for tables of contents
- 51. Tags for tables of contents
- 52. Abbreviations as ad-hoc variables
- 53. Abbreviations as ad-hoc variables
- 54. Abbreviations as ad-hoc variables
- 55. Finding stuff Highlight search
- 56. Finding stuff Highlight search Incremental search
- 57. Finding stuff Highlight search Incremental search regexp search
- 58. documenting.css
- 59. How do you do this stuff? Write it down.
- 60. How do you do this stuff? Write it down. Congratulations! You just wrote documentation.
- 61. You should document two things: your conventions & your code.
- 62. Use comments in the . This is where comes to life; it’s where other developers must understand what it’s doing.
- 63. You can generate documentation from your comments.
- 64. Documentation generation with Natural Docs
- 65. Documentation generation with Natural Docs
- 66. Documentation generation with Natural Docs
- 67. Documentation generation with Natural Docs
- 68. Organize your files Write quality code Document code & conventions
- 69. Something we need: An app/script which alerts us to unused selectors, etc. Anyone?
- 70. Thank you! These slides will be posted on www.the-haystack.com/presentations/fronteers2008/