3. 2.4.2019 Sass Best Practices 3sudotec
Ablauf
● Was ist das Problem mit CSS?
● Was ist Sass?
● Sass Geschichte
● Styleguide
● Partials
● Ordnerstruktur
● Framworks
● Mixins/Placehoders
● Beispiele
●
Umsetzung
4. 2.4.2019 Sass Best Practices 4sudotec
Probleme mit CSS
CSS neigt zur Unübersichtlichkeit
Gründe:
1
2
3
4
Spoiler => hier kann Sass helfen!
Syntax: Unterschiedliche
Autoren = unterschiedliche
Formatierungen/Ansätze
Struktur: Html-Selektoren-
Ketten
Filegröße: CSS wächst
mit der Zeit, bildet oft
Arbeits-Chronologie ab
Inhalt: enthält häufig
Wiederholungen
5. 2.4.2019 Sass Best Practices 5sudotec
Was ist Sass?
● Sass ist ein Präprozessor
● Er beseitigt die Fehler von CSS
●
kein Allheilmittel
● muss richtig angewendet werden
● wer es einmal nutzt, will es nie wieder
missen
● Alternativen: less, stylus
6. 2.4.2019 Sass Best Practices 6sudotec
Sass Geschichte
● 2006 als Ruby-Projekt gestartet
● inzwischen auf C++ portiert (LibSass)
● Einbindung jetzt deutlich einfacher
●
Ursprungs-Syntax: sass (basierend auf
Einrückungen)
●
Neue Syntax: scss (kompatibel zu css)
●
Jedes css-File ist zugleich gültiges
scss-File!
// Variable
!primary-color= hotpink
// Mixin
=border-radius(!radius)
-webkit-border-radius= !radius
-moz-border-radius= !radius
border-radius= !radius
.my-element
color= !primary-color
width= 100%
overflow= hidden
.my-other-element
+border-radius(5px)
// Variable
$primary-color: hotpink;
// Mixin
@mixin border-radius($radius) {
-webkit-border-radius: $radius;
-moz-border-radius: $radius;
border-radius: $radius;
}
.my-element {
color: $primary-color;
width: 100%;
overflow: hidden;
}
.my-other-element {
@include border-radius(5px);
}
sass-syntax scss-syntax
7. 2.4.2019 Sass Best Practices 7sudotec
Wie Sass hilft
● Variablen
● Partials
● Mixins
● Placeholders
● Styleguide
● Ordnerstruktur
● HTML-Struktur
● CSS-Linter
Das bringt SASS mit
Das müssen wir
selbst erledigen
8. 2.4.2019 Sass Best Practices 8sudotec
Styleguide
Styleguide umso wichtiger
●
je mehr Teammitglieder
● je komplexer das Projekt
● je länger das Projekt läuft
●
je mehr Projekte pro Teammitglied
Haupt-Regeln
●
Einrückung 2 Leerstellen
● Zeilen max. 80 Zeichen
● Je Zeile nur eine Regel, je Zeile nur einen
Selektor
● Sinnvolle Leerzeilen
● Kommentare
.foo, .bar {
display: block; overflow: hidden;
padding: 0px 1em;
color:#ffffff;
}
.foo {display: block; overflow: hidden}
// some valuable comment
.foo {
display: block;
overflow: hidden;
padding: 0 1em;
}
.bar,
.foobar < .baz {
color: #fff;
}
je komplex desto styleguide
1
gut
ungut
9. 2.4.2019 Sass Best Practices 9sudotec
Styleguide (extended)
IDs – nicht für Styling nutzen
● unübersichtlich
● widerspricht der
Wiederverwendbarkeit
● gegen IDs als
Sprungmarken oder als
Selektoren für js ist nichts
einzuwenden
1
<section id="footer">
<p class="error">Fehlertext.</p>
</section>
#footer p{
color: black;
}
p.error{
color: red;
}
#footer p.error{
color: red;
}
p.error{
color: red !important;
}
html
css
10. 2.4.2019 Sass Best Practices 10sudotec
Exkurs: Specificity-Wars
● spezifischere Regel gewinnt
● bei gleicher Spezifität gewinnt die spätere Regel
● (fast) kein Übergang von einer Stelle in die
nächste => abhängig von Implementation
a 0,0,0,0,1
p a 0,0,0,0,2
.foo 0,0,0,1,0
a.foo 0,0,0,1,1
p a.foo 0,0,0,1,2
.foo .bar 0,0,0,2,0
div[id=foo] 0,0,0,1,1
#foo 0,0,1,0,0
inline-style 0,1,0,0,0
!important 1,0,0,0,0
So werten Browser die Regeln aus
11. 2.4.2019 Sass Best Practices 11sudotec
Styleguide (extended)
● !important – (fast) nicht nutzen
Ausnahmen:
.hidden {
display: none !important;
}
// my comment, what is intended here
// and why an „important“-statement is needed
.page_42 {
.news a {
color: $secondary !important;
}
}
1
Shame-Dateigenerische Klassen
12. 2.4.2019 Sass Best Practices 12sudotec
Styleguide (extended)
● Selektorentiefe:
maximal 3 Ebenen
●
Das ist eine Regel mit starken Implikationen für html, Wahl der
Klassenbezeichnungen und Strukur des css
● Verschachtelungstiefe kann reduziert werden durch Wahl von Klassennamen
// no
body .main .news .news-list a > ul > ul {
padding-left: 5px;
}
// yes
.main-content .news-list a {
color: green;
}
2
14. 2.4.2019 Sass Best Practices 14sudotec
Sass-Partials 3
●
file.scss wird übersetzt zu
file.css
●
_file.scss wird nicht übersetzt
●
Partials einbinden mit
„@import „file“;
●
kein Performance-Verlust, weil
sass die Files zu einem css-File
zusammenfügt!
●
alle Partials im Haupt-File
sammeln: main.scss
// Einstellungen (Nur Definitionen. Keine Sass-Anweisungen)
@import '1-Settings/glyphicons';
@import '1-Settings/mixins';
@import '1-Settings/breakpoints';
@import "1-Settings/bootstrap_variables";
// Bibliotheken (Externe Libraries)
@import "2-Libraries/bootstrap-4.0.0/scss/bootstrap";
// generelle Komponenten ( seitenweite Geltung)
@import "3-Base/debug";
@import "3-Base/Global";
// Einstellungen für Seitenbereiche (für Unterbereiche der Seite)
@import "4-Zones/Footer";
@import "4-Zones/Content";
// Menüs
@import "5-Menus/Mainnav";
@import "5-Menus/Metanav";
// Seitenelemente (alle Typo3-Elemente und unsere Elemente)
@import "6-Components/Kartenteaser";
@import "6-Components/Slider";
@import "6-Components/Stoerer";
// Extensions
@import "7-Extensions/news";
// Hacks für einzelne Seiten
@import "8-Specific/startseite";
@import "8-Specific/shame";
Typischer Inhalt von main.scss
15. 2.4.2019 Sass Best Practices 15sudotec
Ordnerstruktur 3
●
Ordnung:
Allgemein -> Speziell
● Nur „1-Settings“
=> kein Output
● Bis „2-Libraries“
=> angepasstes Bootstrap
●
Bis „3-Base“
=> Seite mit Grundeinstellungen
● Abschnitt 4: Unterbereiche der Seite
●
Abschnitte 5-7 können je nach
Bedarf auch zusammengefasst oder
anders strukturiert werden
●
Abschnitt 8: Styles für Einzelseiten,
spezielle Hacks
● Ordner liegen in:
sitepackage/Resources/Private/Sass
● 1-Settings
● 2-Libraries
● 3-Base
● 4-Zones
● 5-Menus
● 6-Components
● 7-Extensions
● 8-Specific
main.scss
16. 2.4.2019 Sass Best Practices 16sudotec
Sass Variable 4
Beispiel: Farben
h1 {
background-color: #b0eb00;
}
a {
color: #b0eb00;
}
button {
border-color: #b0eb00;
}
css
$yellow-green: #b0eb00;
h1 {
background-color: $yellow-green;
}
a {
color: $yellow-green;
}
button {
border-color: $yellow-green;
}
sass 1
● Unübersichtlich
● Kein innerer
Zusammenhang
● schwer zu lesen
besser, aber:
● Farbnamen nehmen schnell
überhand
● was, wenn sich die Farbe
prinzipiell ändert?
$yellow-green: #b0eb00;
$primary: $yellow-green;
h1 {
background-color: $primary;
}
a {
color: $primary;
}
button {
border-color: $primary;
}
sass 2
gut:
● im ersten Schritt Farben lesbar
machen
● im zweiten Schritt auf Funktions-
Farbnamen zuweisen
● Farbzuweisungen in
1-settings/colors
● Varianten über sass-Farbfunktionen
21. 2.4.2019 Sass Best Practices 21sudotec
Beispiel: Media Queries
●
Media-Queries in mixins auslagern
●
wird meist von den Frameworks schon
angeboten
● nötigenfalls erweitern oder von
anderen Frameworks kopieren
●
sass gestattet die Verwendung
irgendwo im Code
@media (max-width: 991px) {
.header-image, #meta-nav, #main-nav {position:relative}
#main-nav {top:0}
...
}
.logo {
...
top: 125px;
@include media-breakpoint-down(sm) {
top: 25px;
}
}
css: Oft Block am Ende
sass
22. 2.4.2019 Sass Best Practices 22sudotec
Umsetzung
1) phpstorm mit filewatcher
● Pro: geht einfach
● Con: nicht versionierbar
●
Con: kein Linter2) grunt (oder anderer Taskrunner)
●
Pro: Versionierbar
● incl Autoprefixer
● incl stylelinter
● Con: kann kompliziert werden
module.exports = function(grunt) {
grunt.initConfig({
// Lint all SCSS files before compilation
stylelint: {
files: [
'extensions/sitepackage/Resources/Private/Sass/**/*.scss',
'!extensions/sitepackage/Resources/Private/Sass/2-Libraries/**/*.scss'
]
},
// Convert SCSS files to regular single CSS file
sass: {
layout: {
options: {
sourceMap: true,
outputStyle: 'expanded'
},
src: ['extensions/sitepackage/Resources/Private/Sass/main.scss'],
dest: 'extensions/sitepackage/Resources/Public/Css/main.css'
}
},
// Add vendor prefixes to CSS file, according to browserlist file
postcss: {
layout: {
src: 'extensions/sitepackage/Resources/Public/Css/main.css',
options: {
map: true,
processors: [
require('autoprefixer')()
]
}
}
},
// Watch these files and directories
watch: {
grunt: {
files: ['Gruntfile.js', 'package.json']
},
sass_layout: {
files: ['extensions/sitepackage/Resources/Private/Sass/**/*.scss'],
tasks: ['stylelint', 'sass:layout', 'postcss:layout']
}
}
});
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-stylelint');
grunt.loadNpmTasks('grunt-sass');
grunt.loadNpmTasks('grunt-postcss');
grunt.registerTask('default', ['watch']);
};
23. 2.4.2019 Sass Best Practices 23sudotec
Zusammenfassung
● Styleguide erstellen und konsequent nutzen,
am besten mit Stylelinter
● Alle sass-Files in klare Ordnerstruktur
auslagern (Partials)
● Möglichst einfachen Code schreiben
● viel kommentieren
● Spaß haben!
Kompliziertes Thema,
hier nur meine Ansicht
es gibt viele verschiedene
hängt auch von Projektgrößen ab
Disclaimer: Das wird eine Werbeveranstaltung für Sass. Ich werde von denen nicht bezahlt und habe auch keine Verwandten die davon profitieren ;-)
Bild als symbol für das Durcheinander.
Kabel neigen zum Verheddern
genauso Spanngummis
auf Icons hinweisen
unterschiedliche Autoren = ich selbst vor einem Jahr
So schön geordnet soll es werden
Sieht langweilig aus, ist aber voll cool
Sass ist Werkzeug
Man schreibt sass, schickt es durch einen Compilier und bekommt css raus.
Kann man sich anschauen
Sollte man tun!
im folgenden scss gemeint, wenn sass geschrieben
rot umrandet = schlecht
Vermeiden:
- zwei Selektoren in einer Zeile
- zwei Deklarationen in einer Zeile
- sinnlose Leerzeilen
- 0px
- #ffffff statt #fff
- keine Leerzeile nach schließender Klammer
Zu Color-Werten gibt es noch weitere Meinungen
Variante 1: geht nicht
nur 2 oder 3
2 nicht wiederverwendbar
3 mit Seiteneffekten
Oft werden nur die letzten drei Spalten gezeigt
Versuch: 256 Klassen = 1 ID
generisch: Was überall gilt, und sich immer durchsetzen soll.
werden nur wenige Regeln sein
Shame-Datei: Sammlung letzter Dinge, sollte leer sein.
2 = Struktur
Problem werden wir noch sehen:
Frameworks (wie Bootstrap). Sie müssen allgemein sein und haben keine Möglichkeit, auf spezielle Klassen auszuweichen.
Ansonsten reichen drei Ebenen aus.
Disziplin: man muss dann halt überlegen: Soll das für alle Typo3-CEs gelten, oder nur für die Menüs, oder nur für das subpages-Menu.
Doppel-Unterstrich
Namen nicht schön, aber modular
3 = Länge
man packt alles in einzelne Files, so geordnet wie möglich.
erhöht die Wiederverwendbarkeit enorm
anders als css-include kein Performance-Verlust
3 = Länge
1: Sass-Variablen, Mixins, Placeholder
Zones-Konzept: 1. Ebene unterhalb body
nicht überlappend, voll überdeckend
Gibt dann natürlich Grenzfragen:
- ist footer eine Zone oder eine Komponente
5 könnte man als Komponente betrachten, finde ich aber einfacher zu finden. Menüs sind meist kompliziert
7 sind auch Komponenten, aber wegen typo3 sind Extensions extra
8 enthält die Shame-Datei
4 und 5-7 widersprechen sich. Was, wenn News im Header anders aussehen als im Content-Bereich: Dann in news
4 = Wiederholungen
Nur css-Ausschnitt
sass 1: erster Versuch
Farbdeklaration in eigenes File.
sass 2: Auch hier Farben in eignes File
Farbvarianten: $primary-light, $primary-dark, $secondary, $neutral,
Immer zunächst die Möglichkeiten des Frameworks nutzen, ehe man überschreibt.
Bootstrap-Datei ist leider nicht kommentiert. In eigener Datei main.scss vermeiden. Ist „Inhaltsverzeichnis“
Bislang: Zonen- Komponenten, eine Art Baumstruktur.
Quer dazu: Mixins
Dokumentation lesen! viele weitere Möglichkeiten
sprengen den Rahmen
refactoring ist spannend, weil man von allein Schwächen findet und ausbügelt
im Mixin kann Intelligenz stecken:
If-Abfragen für bestimmt Icons.
Könnte auch andere Zeichensätze (font-awesome) mitnehmen.
Placeholder sind relativ neu
man kann häufig genutzte Mixins ausgliedern
placeholder = mixin(fester Wert)
Vorteil: Media-Queries da, wo man sie versteht.
media-queries noch komplizierter bei Zwischenbereich.
Beispiel: Foundation
Auf mobile-first ausgelegt (nur media-breakpoint-up vorhanden)
Entwurf aber desktop-only
also media-breakpoint-down neu angelegt
grunt hat gewisse Hürden, aber lohnt sich wegen der Einbindung verschiedener Tasks.
phpstorm ist gut für schnelle Bearbeitung.
Vielleicht Kombination möglich... phpstorm für Develop, grunt für Live...
Style-Linter sind eine eigene Erfahrung. Da lernt man was „kleinlich“ bedeutet.
Nicht behandelt: Die Reihenfolge von Anweisungen. Siehe dazu die Links
Generell gilt:
Nicht verkünsteln!
Immer so einfach wie möglich
lerne die Regeln, damit du sie richtig brechen kannst
// kommentare werden nicht übersetzt