You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+31-31Lines changed: 31 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -68,15 +68,15 @@ Finally, properties are what give the selected elements of a rule declaration th
68
68
69
69
### Formatting
70
70
71
-
* Use soft tabs (2 spaces) for indentation
72
-
* Prefer dashes over camelCasing in class names.
71
+
- Use soft tabs (2 spaces) for indentation
72
+
- Prefer dashes over camelCasing in class names.
73
73
- Underscores and PascalCasing are okay if you are using BEM (see [OOCSS and BEM](#oocss-and-bem) below).
74
-
* Do not use ID selectors
75
-
* When using multiple selectors in a rule declaration, give each selector its own line.
76
-
* Put a space before the opening brace `{` in rule declarations
77
-
* In properties, put a space after, but not before, the `:` character.
78
-
* Put closing braces `}` of rule declarations on a new line
79
-
* Put blank lines between rule declarations
74
+
- Do not use ID selectors
75
+
- When using multiple selectors in a rule declaration, give each selector its own line.
76
+
- Put a space before the opening brace `{` in rule declarations
77
+
- In properties, put a space after, but not before, the `:` character.
78
+
- Put closing braces `}` of rule declarations on a new line
79
+
- Put blank lines between rule declarations
80
80
81
81
**Bad**
82
82
@@ -109,30 +109,30 @@ Finally, properties are what give the selected elements of a rule declaration th
109
109
110
110
### Comments
111
111
112
-
* Prefer line comments (`//` in Sass-land) to block comments.
113
-
* Prefer comments on their own line. Avoid end-of-line comments.
114
-
* Write detailed comments for code that isn't self-documenting:
112
+
- Prefer line comments (`//` in Sass-land) to block comments.
113
+
- Prefer comments on their own line. Avoid end-of-line comments.
114
+
- Write detailed comments for code that isn't self-documenting:
115
115
- Uses of z-index
116
116
- Compatibility or browser-specific hacks
117
117
118
118
### OOCSS and BEM
119
119
120
120
We encourage some combination of OOCSS and BEM for these reasons:
121
121
122
-
* It helps create clear, strict relationships between CSS and HTML
123
-
* It helps us create reusable, composable components
124
-
* It allows for less nesting and lower specificity
125
-
* It helps in building scalable stylesheets
122
+
- It helps create clear, strict relationships between CSS and HTML
123
+
- It helps us create reusable, composable components
124
+
- It allows for less nesting and lower specificity
125
+
- It helps in building scalable stylesheets
126
126
127
127
**OOCSS**, or “Object Oriented CSS”, is an approach for writing CSS that encourages you to think about your stylesheets as a collection of “objects”: reusable, repeatable snippets that can be used independently throughout a website.
- Smashing Magazine's [Introduction to OOCSS](http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/)
131
131
132
132
**BEM**, or “Block-Element-Modifier”, is a _naming convention_ for classes in HTML and CSS. It was originally developed by Yandex with large codebases and scalability in mind, and can serve as a solid set of guidelines for implementing OOCSS.
- Harry Roberts' [introduction to BEM](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/)
136
136
137
137
We recommend a variant of BEM with PascalCased “blocks”, which works particularly well when combined with components (e.g. React). Underscores and dashes are still used for modifiers and children.
138
138
@@ -163,9 +163,9 @@ function ListingCard() {
163
163
.ListingCard__content { }
164
164
```
165
165
166
-
*`.ListingCard` is the “block” and represents the higher-level component
167
-
*`.ListingCard__title` is an “element” and represents a descendant of `.ListingCard` that helps compose the block as a whole.
168
-
*`.ListingCard--featured` is a “modifier” and represents a different state or variation on the `.ListingCard` block.
166
+
-`.ListingCard` is the “block” and represents the higher-level component
167
+
-`.ListingCard__title` is an “element” and represents a descendant of `.ListingCard` that helps compose the block as a whole.
168
+
-`.ListingCard--featured` is a “modifier” and represents a different state or variation on the `.ListingCard` block.
169
169
170
170
### ID selectors
171
171
@@ -202,14 +202,15 @@ Use `0` instead of `none` to specify that a style has no border.
202
202
border: 0;
203
203
}
204
204
```
205
+
205
206
**[⬆ back to top](#table-of-contents)**
206
207
207
208
## Sass
208
209
209
210
### Syntax
210
211
211
-
* Use the `.scss` syntax, never the original `.sass` syntax
212
-
* Order your regular CSS and `@include` declarations logically (see below)
212
+
- Use the `.scss` syntax, never the original `.sass` syntax
213
+
- Order your regular CSS and `@include` declarations logically (see below)
213
214
214
215
### Ordering of property declarations
215
216
@@ -225,7 +226,7 @@ Use `0` instead of `none` to specify that a style has no border.
225
226
}
226
227
```
227
228
228
-
2. `@include` declarations
229
+
1. `@include` declarations
229
230
230
231
Grouping `@include`s at the end makes it easier to read the entire selector.
231
232
@@ -238,7 +239,7 @@ Use `0` instead of `none` to specify that a style has no border.
238
239
}
239
240
```
240
241
241
-
3. Nested selectors
242
+
1. Nested selectors
242
243
243
244
Nested selectors, _if necessary_, go last, and nothing goes after them. Add whitespace between your rule declarations and nested selectors, as well as between adjacent nested selectors. Apply the same guidelines as above to your nested selectors.
244
245
@@ -282,10 +283,9 @@ Mixins should be used to DRY up your code, add clarity, or abstract complexity--
282
283
283
284
When selectors become this long, you're likely writing CSS that is:
284
285
285
-
* Strongly coupled to the HTML (fragile) *—OR—*
286
-
* Overly specific (powerful) *—OR—*
287
-
* Not reusable
288
-
286
+
- Strongly coupled to the HTML (fragile) *—OR—*
287
+
- Overly specific (powerful) *—OR—*
288
+
- Not reusable
289
289
290
290
Again: **never nest ID selectors!**
291
291
@@ -301,7 +301,7 @@ If you must use an ID selector in the first place (and you should really try not
"comment": "MD022: Headers should be surrounded by blank lines",
71
+
"comment": "Some headers have preceeding HTML anchors. Unfortunate that we have to disable this, as it otherwise catches a real problem that trips up some Markdown renderers",
72
+
"blanks-around-headers": false,
73
+
74
+
"comment": "MD023: Headers must start at the beginning of the line",
75
+
"header-start-left": true,
76
+
77
+
"comment": "MD024: Disallow multiple headers with the same content",
78
+
"no-duplicate-header": true,
79
+
80
+
"comment": "MD025: Disallow multiple top level headers in the same document",
81
+
"comment": "Gotta have a matching closing brace at the end",
82
+
"single-h1": false,
83
+
84
+
"comment": "MD026: Disallow trailing punctuation in header",
85
+
"comment": "Gotta have a semicolon after the ending closing brace",
86
+
"no-trailing-punctuation": {
87
+
"punctuation" : ".,:!?"
88
+
},
89
+
"comment": "MD027: Dissalow multiple spaces after blockquote symbol",
90
+
"no-multiple-space-blockquote": true,
91
+
92
+
"comment": "MD028: Blank line inside blockquote",
93
+
"comment": "Some 'Why?' and 'Why not?' blocks are separated by a blank line",
94
+
"no-blanks-blockquote": false,
95
+
96
+
"comment": "MD029: Ordered list item prefix",
97
+
"ol-prefix": {
98
+
"style": "one"
99
+
},
100
+
101
+
"comment": "MD030: Spaces after list markers",
102
+
"list-marker-space": {
103
+
"ul_single": 1,
104
+
"ol_single": 1,
105
+
"ul_multi": 1,
106
+
"ol_multi": 1
107
+
},
108
+
109
+
"comment": "MD031: Fenced code blocks should be surrounded by blank lines",
110
+
"blanks-around-fences": true,
111
+
112
+
"comment": "MD032: Lists should be surrounded by blank lines",
113
+
"comment": "Some lists have preceeding HTML anchors. Unfortunate that we have to disable this, as it otherwise catches a real problem that trips up some Markdown renderers",
114
+
"blanks-around-lists": false,
115
+
116
+
"comment": "MD033: Disallow inline HTML",
117
+
"comment": "HTML is needed for explicit anchors",
118
+
"no-inline-html": false,
119
+
120
+
"comment": "MD034: No bare URLs used",
121
+
"no-bare-urls": true,
122
+
123
+
"comment": "MD035: Horizontal rule style",
124
+
"hr-style": {
125
+
"style": "consistent"
126
+
},
127
+
128
+
"comment": "MD036: Do not use emphasis instead of a header",
0 commit comments