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: sass-style-guide.md
+111-6Lines changed: 111 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,7 @@
7
7
-[Style-Definitionen](#style-definitionen)
8
8
-[Syntax und Formatierung](#syntax-und-formatierung)
9
9
-[Mixins vs. Extends](#mixins-vs-extends)
10
+
-[Media Queries](#media-queries)
10
11
-[Kommentare](#kommentare)
11
12
-[Linting](#linting)
12
13
-[EditorConfig](#editorconfig)
@@ -150,29 +151,108 @@ Um nicht ständig nach einer CSS-Eigenschaft suchen zu müssen, verwenden wir ei
150
151
151
152
Wir arbeiten ausschließlich mit Mixins, [da Extends einige Nachteile mit sich bringen.](https://www.sitepoint.com/avoid-sass-extend/)
152
153
153
-
## Kommentare
154
+
## Media Queries
154
155
155
-
Da man bei CSS nicht immer sofort sieht, warum eine Deklaration eingesetzt wird, macht es durchaus Sinn, Code zu kommentieren. Durch die Verwendung von Sass greifen wir dabei auf stille Kommentare zurück, die mit zwei Slashes `// …` eingeleitet werden. In der Regel sind Kommentare nur für die Entwickler wichtig und müssen dadurch nicht im CSS ausgegeben werden. Das reduziert zudem die Dateigröße.
156
+
Um Inhalte optimal für verschiedene Devices und den damit verbundenen Viewports bereitzustellen, setzen wir Media Queries ein. Diese werden mit Hilfe des `respond-to` Mixins in jeder einzelnen Komponente in einem Block am Ende deklariert. Jede Viewport-Range ist dabei in sich geschlossen, d.h. es werden keine Styles aus den anderen Media Queries überschrieben:
156
157
157
-
Möchte man eine einzelne Zeile in einem Block kommentieren, so setzt man den Kommentar ans Ende der Deklaration:
158
+
```
159
+
<--- large --- | --- medium --- | --- small --->
160
+
```
161
+
162
+
Alle Media Queries sind gleichwertig, es gibt kein *Desktop first* oder *Mobile first*. Existieren Styles, die übergreifend für alle Media Queries gleich sind, werden diese oben im Stylesheet festgehalten. Der Dateiaufbau sieht demnach wie folgt aus:
158
163
159
164
```sass
165
+
// Global Styles
160
166
.box
161
-
position: absolute
162
-
top: -12px // Fallback if JS fails to load
167
+
…
168
+
169
+
// Media Queries
170
+
+respond-to(large)
171
+
.box
172
+
…
173
+
174
+
+respond-to(medium)
175
+
.box
176
+
…
177
+
178
+
+respond-to(small)
179
+
.box
180
+
…
163
181
```
164
182
165
-
Möchte man dagegen einen kompletten Block beschreiben, so setzt man den Kommentar direkt darüber:
183
+
**Vorteile:**
184
+
185
+
-**Effizienz** – Styling-Anpassungen sind schneller und gezielter zu bewerkstelligen. Tritt z.B. auf Smartphone XY ein Darsellungsfehler auf oder man möchte ein Element für die kleinste Viewport-Range optimieren, dann steuert man direkt den Block unter `+respond-to(small)` an und macht dort seine Änderungen.
186
+
-**Leserlichkeit** – Dadurch, dass alle Media Query Definitionen en bloc am Ende stehen, sind sie nicht nur leichter aufzufinden, das Stylesheet bleibt obendrein auch leserlich. Würde man die Media Queries direkt ans Element schreiben, enstünde durch die ständige Einrückung im Code ein stockender Lesefluss.
187
+
-**Wartbarkeit** – Bei dieser Vorgehensweise ist zudem mit weniger ungewollten Seiteneffekten zu rechnen. Es können keine Fehler in anderen Media Queries entstehen, da diese voneinander abgeschottet sind.
188
+
189
+
**Nachteile:**
190
+
191
+
- Es könnte der Eindruck enstehen, dass Code dupliziert bzw. wiederholt geschrieben und somit gegen das DRY-Prinzip verstoßen wird, weil anstatt von zwei Definitionen (global plus einmal überschreiben) nun immer drei (alle Media Queries) gesetzt werden müssen. Dem ist jedoch nicht so! Die Erfahrung zeigt, dass eine Änderung in nur einer Media Query eher die Seltenheit ist. In der Regel werden zwei oder gleich alle drei angepasst. Sollte dies dennoch mal passieren, sind die zuzätzlichen Bytes locker zu verkraften.
192
+
193
+
### Vorgehensweise
194
+
195
+
Schritt eins, man definiert seine `$breakpoints` in den entsprechenden [Settings](https://github.com/zweitag/rails-project-template/blob/master/app/assets/stylesheets/utilities/_responsify.css.sass). **Hinweis:** Auf mehr als drei Media Queries sollte man nicht zurückgreifen, da dies den Komplexitätsgrad und den damit verbundenen Zeitaufwand enorm in die Höhe treibt.
196
+
197
+
Beginnt man nun damit die Komponente grundlegend zu stylen, wandern erst einmal alle Style-Definitionen in den globalen Bereich.
198
+
199
+
```sass
200
+
// Global Styles
201
+
.box
202
+
position: relative
203
+
margin-top: 20px
204
+
color: $accent-color
205
+
```
206
+
207
+
Möchte man eine neue Eigenschaft für eine bestimmte Viewport-Range hinzufügen, so setzt man diese in der entsprechenden Media Query.
166
208
167
209
```sass
168
210
// Global Styles
169
211
.box
170
212
position: relative
213
+
margin-top: 20px
214
+
color: $accent-color
215
+
216
+
// Media Queries
217
+
+respond-to(large)
218
+
.box
219
+
border: 1px solid $border-color
220
+
```
221
+
222
+
Für den Fall, dass man eine bereits global gesetzte Eigenschaft für eine bestimmte Media Query ändern möchte, überschreibt man den globalen Style *nicht*, sondern entfernt ihn aus dem globalen Scope und setzt ihn gleichzeitig für alle Media Queries.
223
+
224
+
**schlecht**
225
+
226
+
```sass
227
+
// Global Styles
228
+
.box
229
+
position: relative
230
+
margin-top: 20px
231
+
color: $accent-color
232
+
233
+
// Media Queries
234
+
+respond-to(large)
235
+
.box
236
+
border: 1px solid $border-color
237
+
238
+
+respond-to(medium)
239
+
.box
240
+
margin-top: 10px
241
+
```
242
+
243
+
**gut**
244
+
245
+
```sass
246
+
// Global Styles
247
+
.box
248
+
position: relative
249
+
color: $accent-color
171
250
172
251
// Media Queries
173
252
+respond-to(large)
174
253
.box
175
254
margin-top: 20px
255
+
border: 1px solid $border-color
176
256
177
257
+respond-to(medium)
178
258
.box
@@ -183,6 +263,31 @@ Möchte man dagegen einen kompletten Block beschreiben, so setzt man den Komment
183
263
margin-top: 5px
184
264
```
185
265
266
+
## Kommentare
267
+
268
+
Da man bei CSS nicht immer sofort sieht, warum eine Deklaration eingesetzt wird, macht es durchaus Sinn, Code zu kommentieren. Durch die Verwendung von Sass greifen wir dabei auf stille Kommentare zurück, die mit zwei Slashes `// …` eingeleitet werden. In der Regel sind Kommentare nur für die Entwickler wichtig und müssen dadurch nicht im CSS ausgegeben werden. Das reduziert zudem die Dateigröße.
269
+
270
+
Möchte man eine einzelne Zeile in einem Block kommentieren, so setzt man den Kommentar ans Ende der Deklaration:
271
+
272
+
```sass
273
+
.box
274
+
position: absolute
275
+
top: -12px // Fallback if JS fails to load
276
+
```
277
+
278
+
Möchte man dagegen einen kompletten Block beschreiben, so setzt man den Kommentar direkt darüber:
279
+
280
+
```sass
281
+
// Global Styles
282
+
.box
283
+
position: relative
284
+
285
+
// Media Queries
286
+
+respond-to(large)
287
+
.box
288
+
margin-top: 20px
289
+
```
290
+
186
291
## Linting
187
292
188
293
Zum Testen unseres Sass-Codes benutzen wir [Sass Lint](https://github.com/sasstools/sass-lint). Die Dokumention der Regeln findet ihr [hier](https://github.com/sasstools/sass-lint/tree/master/docs/rules). Unsere Konfiguration findet man in unserem [Template-Repo](https://github.com/zweitag/rails-project-template/blob/master/.sass-lint.yml).
0 commit comments