Code-Guide/example.html at master · dgowrie/Code-Guide · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
<!DOCTYPE html>
<htmllang="en">
<head>
<metacharset="UTF-8">
<title>Scalable and Modular Front-End Architecture</title>
<linkrel="stylesheet" href="main.css">
</head>
<body>
<divclass="l-user">
<ahref="#">Register</a>
<ahref="#">Sign in</a>
</div>
<divclass="l-header">
<divclass="l-constrained">
<divclass="logo">
<h2class="hd"><ahref="/"><spanclass="hd-line hd-line1">Scalable and Modular</span><spanclass="hd-line hd-line2">Architecture for CSS</span></a></h2>
</div>
</div>
</div>
<divclass="l-content">
<divclass="l-constrained">
<divclass="article"><article><h1>Categorizing CSS Rules</h1>

<p>Every project needs some organization. Throwing every new style you create onto the end of a single file would make finding things more difficult and would be very confusing for anybody else working on the project. Of course, you likely have some organization in place already. Hopefully, what you read among these pages will highlight what works with your existing process and, if I’m lucky, you will see new ways in which you can improve your process.</p>

<p>How do you decide whether to use ID selectors, or class selectors, or any number of selectors that are at your disposal? How do you decide which elements should get the styling magic you wish to bestow upon it? How do you make it easy to understand how your site and your styles are organized? </p>

<p>At the very core of SMACSS is categorization. By categorizing CSS rules, we begin to see patterns and can define better practices around each of these patterns.</p>

<p>There are five types of categories:</p>
<ol>
<li>Base</li>
<li>Layout</li>
<li>Module</li>
<li>State</li>
<li>Theme</li>
</ol>

<p>We often find ourselves mixing styles across each of these categories. If we are more aware of what we are trying to style, we can avoid the complexity that comes from intertwining these rules.</p>

<p>Each category has certain guidelines that apply to it. This somewhat succinct separation allows us to ask ourselves questions during the development process. How are we going to code things and <em>why</em> are we going to code them that way?</p>

<p>Much of the purpose of categorizing things is to codify patterns—things that repeat themselves within our design. Repetition results in less code, easier maintenance, and greater consistency in the user experience. These are all wins. Exceptions to the rule can be advantageous but they should be justified.</p>

<p><strong>Base rules</strong> are the defaults. They are almost exclusively single element selectors but it could include attribute selectors, pseudo-class selectors, child selectors or sibling selectors. Essentially, a base style says that wherever this element is on the page, it should look like <em>this</em>.</p>

<divclass="exm">
<pclass="exm-caption">Examples of Base Styles</p>
<pre><code>html, body, form { margin: 0; padding: 0; }
input[type=text] { border: 1px solid #999; }
a { color: #039; }
a:hover { color: #03C; }</code></pre>
</div>

<p><strong>Layout rules</strong> divide the page into sections. Layouts hold one or more modules together.</p>

<p><strong>Modules</strong> are the reusable, modular parts of our design. They are the callouts, the sidebar sections, the product lists and so on.</p>

<p><strong>State rules</strong> are ways to describe how our modules or layouts will look when in a particular state. Is it hidden or expanded? Is it active or inactive? They are about describing how a module or layout looks on screens that are smaller or bigger. They are also about describing how a module might look in different views like the home page or the inside page.</p>

<p>Finally, <strong>Theme rules</strong> are similar to state rules in that they describe how modules or layouts might look. Most sites don’t require a layer of theming but it is good to be aware of it.</p>

<h2id="naming">Naming Rules</h2>

<p>By separating rules into the four categories, naming convention is beneficial for immediately understanding which category a particular style belongs to and its role within the overall scope of the page. On large projects, it is more likely to have styles broken up across multiple files. In these cases, naming convention also makes it easier to find which file a style belongs to.</p>

<p>I like to use a prefix to differentiate between Layout, State, and Module rules. For Layout, I use <code>l-</code> but <code>layout-</code> would work just as well. Using prefixes like <code>grid-</code> also provide enough clarity to separate layout styles from other styles. For State rules, I like <code>is-</code> as in <code>is-hidden</code> or <code>is-collapsed</code>. This helps describe things in a very readable way.</p>

<p>Modules are going to be the bulk of any project. As a result, having every module start with a prefix like <code>.module-</code> would be needlessly verbose. Modules just use the name of the module itself. </p>

<divclass="exm">
<pclass="exm-caption">Example classes</p>
<pre><code>/* Example Module */
.example { }

/* Callout Module */
.callout { }

/* Callout Module with State */
.callout.is-collapsed { }

/* Form field module */
.field { }

/* Inline layout */
.l-inline { }
</code></pre>
</div>

<p>Related elements within a module use the base name as a prefix. On this site, code examples use <code>.exm</code> and the captions use <code>.exm-caption</code>. I can instantly look at the caption class and understand that it is related to the code examples and where I can find the styles for that.</p>

<p>Modules that are a variation on another module should also use the base module name as a prefix. Sub-classing is covered in more detail in the Module Rules chapter.</p>

<p>This naming convention will be used throughout these pages. Like most other things that I have outlined here, don’t feel like you have to stick to these guidelines rigidly. Have a convention, document it, and stick to it.</p>

</article></div>

<divclass="article-aside nav">

<h4>Preface</h4>
<ol>
<li><ahref="/book/about">About the Author</a>
</li><li><ahref="/book/">Introduction</a>
</li></ol>
<h4>Core</h4>
<olstart="3">
<li><ahref="/book/categorizing">Categorizing CSS Rules</a></li>
<li><ahref="/book/type-base">Base Rules</a></li>
<li><ahref="/book/type-layout">Layout Rules</a></li>
<li><ahref="/book/type-module">Module Rules</a></li>
<li><ahref="/book/type-state">State Rules</a></li>
<li><ahref="/book/type-theme">Theme Rules</a></li>
<li><ahref="/book/state">Changing State</a></li>
</ol>
<h4>Aspects of SMACSS</h4>
<olstart="10">
<li><ahref="/book/applicability">Depth of Applicability</a></li>
<li><ahref="/book/selectors">Selector Performance</a></li>
<li><ahref="/book/html5">HTML5 and SMACSS</a></li>
<li><ahref="/book/prototyping">Prototyping</a></li>
</ol>
<h4>Aspects (cont) <em>Member Only</em></h4>
<olstart="14">
<li><ahref="/book/preprocessors">Preprocessors</a> (new)</li>
<li><ahref="/book/icon-module">The Icon Module</a></li>
<li><ahref="/book/screencast-1">Screencast: Applying the Principles</a></li>
</ol>
<h4>Appendix</h4>
<olstart="17">
<li><ahref="/book/formatting">Formatting Code</a></li>
<li><ahref="/book/resources">Resources</a></li>
<li><ahref="/book/changelog">Changelog</a></li>
</ol>

</div>

</body></html>