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.

1. maintainable.css
Stephen Hay . Fronteers, Amsterdam . 20080911

6. #maintainable.css {
organizing: yes;
authoring: quality;
documenting: please;
}

7. organizing.css

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]-->

19. Use version control.

20. authoring.css

21. {
focus: less-here;
}

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/