Ein meist vernünftiger Ansatz für CSS und Sass
Eine "Regeldeklaration" ist der Name eines Selektors (oder einer Gruppe von Selektoren) mit einer zugehörigen Gruppe von Eigenschaften. Hier ist ein Beispiel:
.listing {
font-size: 18px;
line-height: 1.2;
}In einer Regeldeklaration sind "Selektoren" die Werte, die bestimmen, welche Elemente im DOM-Baum durch die definierten Eigenschaften gestylt werden. Selektoren können sowohl HTML-Elemente als auch die Klasse, ID oder eines der Attribute eines Elements abgleichen. Hier sind einige Beispiele von Selektoren:
.my-element-class {
/* ... */
}
[aria-hidden] {
/* ... */
}Schließlich geben Eigenschaften den ausgewählten Elementen einer Regeldeklaration ihren Stil. Eigenschaften sind Schlüssel-Wert-Paare, und eine Regeldeklaration kann eine oder mehrere Eigenschaftsdeklarationen enthalten. Eigenschaftsdeklarationen sehen so aus:
/* some selector */ {
background: #f1f1f1;
color: #333;
}- Verwende Soft Tabs (2 Leerzeichen) für die Einrückung.
- Bevorzuge Bindestriche gegenüber camelCasing in Klassennamen.
- Unterstriche und PascalCasing sind in Ordnung, wenn Sie BEM verwenden (siehe OOCSS und BEM unten).
- Nutze keine ID Selektoren
- Wenn Du mehrere Selektoren in einer Regeldeklaration verwenden, gib jedem Selektor eine eigene Zeile.
- Setze ein Leerzeichen vor die öffnende Klammer
{in Regeldeklarationen. - Setze in Eigenschaften ein Leerzeichen nach, aber nicht vor dem Zeichen
: - Setze schließende Klammern
}von Regeldeklarationen auf eine neue Zeile. - Setze Leerzeilen zwischen Regeldeklarationen.
Schlecht
.avatar{
border-radius:50%;
border:2px solid white; }
.no, .nope, .not_good {
// ...
}
#lol-no {
// ...
}Gut
.avatar {
border-radius: 50%;
border: 2px solid white;
}
.one,
.selector,
.per-line {
// ...
}- Bevorzuge Zeilen-Kommentare (
//in Sass-Land), vor Blockkommentaren. - Bevorzuge Kommentare auf einer eigenen Zeile. Vermeide Kommentare am Zeilenende.
- Schreibe detaillierte Kommentare für Code, der nicht selbstdokumentierend ist:
- Nutzung des z-index
- Kompatibilität oder browserspezifische Hacks
Aus diesen Gründen empfehlen wir eine Kombination von OOCSS und BEM:
- Es hilft, klare, strenge Beziehungen zwischen CSS und HTML zu schaffen.
- Es hilft uns, wiederverwendbare, zusammensetzbare Komponenten zu schaffen.
- Es ermöglicht eine geringere Verschachtelung und eine geringere Spezifizität.
- Es hilft bei der Erstellung skalierbarer Stylesheets.
OOCSS, oder "Object Oriented CSS", ist ein Ansatz zum Schreiben von CSS, der Dich dazu anregt, Deine Stylesheets als eine Sammlung von "Objekten" zu betrachten: wiederverwendbare, wiederholbare Schnipsel, die unabhängig voneinander auf einer Website verwendet werden können.
- Nicole Sullivan's OOCSS wiki (Englisch)
- Smashing Magazine's Introduction to OOCSS (Englisch)
BEM, oder "Block-Element-Modifier", ist eine Namenskonvention für Klassen in HTML und CSS. Es wurde ursprünglich von Yandex mit großen Codebasen und Skalierbarkeit im Auge entwickelt und kann als eine solide Reihe von Richtlinien für die Umsetzung von OOCSS dienen.
- CSS Trick's BEM 101 (Englisch)
- Harry Roberts' introduction to BEM (Englisch)
Wir empfehlen eine Variante von BEM mit PascalCased "Blöcken", die in Kombination mit Komponenten (z.B. React) besonders gut funktioniert. Unterstriche und Bindestriche werden weiterhin für Modifikatoren und Kinder verwendet.
Beispiel
// ListingCard.jsx
function ListingCard() {
return (
<article class="ListingCard ListingCard--featured">
<h1 class="ListingCard__title">Adorable 2BR in the sunny Mission</h1>
<div class="ListingCard__content">
<p>Vestibulum id ligula porta felis euismod semper.</p>
</div>
</article>
);
}/* ListingCard.css */
.ListingCard { }
.ListingCard--featured { }
.ListingCard__title { }
.ListingCard__content { }.ListingCardist der "Block" und stellt die übergeordnete Komponente dar..ListingCard__titleist ein "Element" und repräsentiert einen Nachfahren von.ListingCard, der hilft, den Block als Ganzes zu bilden..ListingCard--featuredist ein "Modifikator" und repräsentiert einen anderen Zustand oder eine andere Variante des.ListingCardBlocks.
Es ist zwar möglich, Elemente nach ID in CSS auszuwählen, sollte aber generell als Anti-Pattern betrachtet werden. ID-Selektoren führen ein unnötig hohes Maß an Spezifität in Ihre Regeldeklarationen ein und sind nicht wiederverwendbar.
Weitere Informationen zu diesem Thema findest Du im Artikel von CSS Wizardry's (Englisch) über den Umgang mit der Spezifität.
Vermeide die Bindung an die gleiche Klasse in Deinem CSS und JavaScript. Das Zusammenführen der beiden führt oft zu einem Minimum an Zeitverschwendung beim Refactoring, wenn ein Entwickler jede Klasse, die er ändert, vergleichen muss. Im schlimmsten Fall haben Entwickler Angst, Änderungen vorzunehmen, aus Sorge, die Funktionalität zu brechen.
Wir empfehlen, JavaScript-spezifische Klassen zu erstellen, die mit dem Präfix .js- versehen sind:
<button class="btn btn-primary js-request-to-book">Request to Book</button>Verwende 0 anstelle von none, um anzugeben, dass ein Stil keinen Rahmen hat.
Schlecht
.foo {
border: none;
}Gut
.foo {
border: 0;
}- Verwende die
.scssSyntax, niemals die ursprüngliche.sassSyntax. - Ordne Deine regulären CSS und
@includeDeklarationen logisch an (siehe unten)
-
Eigenschaftsdeklarationen
Listet alle Standard-Eigenschaftsdeklarationen auf, alles, was kein
@includeoder ein geschachtelter Selektor ist..btn-green { background: green; font-weight: bold; // ... }
-
@includeDeklarationenDie Gruppierung von
@includeam Ende erleichtert das Lesen des gesamten Selektors..btn-green { background: green; font-weight: bold; @include transition(background 0.5s ease); // ... }
-
Verschachtelte Selektoren
Verschachtelte Selektoren, wenn nötig, gehen zuletzt, und nichts geht ihnen nach. Füge Leerzeichen zwischen Deine Regeldeklarationen und verschachtelten Selektoren sowie zwischen benachbarten verschachtelten Selektoren hinzu. Wende die gleichen Richtlinien wie oben auf Deine verschachtelten Selektoren an.
.btn { background: green; font-weight: bold; @include transition(background 0.5s ease); .icon { margin-right: 10px; } }
Bevorzuge Variablennamen mit Bindestrich (z.B. $my-variable) gegenüber camelCased oder snake_cased Variablennamen. Es ist zulässig, Variablennamen, die nur innerhalb derselben Datei verwendet werden sollen, einen Unterstrich voranzustellen (z.B. $_my-variable).
Mixins sollten verwendet werden, um Deinen Code zu verbessern, Klarheit oder abstrakte Komplexität zu schaffen - ähnlich wie gut benannte Funktionen. Mixins, die keine Argumente akzeptieren, können dafür nützlich sein, aber beachte, dass, wenn Du Deine Nutzdaten nicht komprimieren (z.B. gzip), dies zu unnötiger Code-Verdopplung in den resultierenden Stilen beitragen kann.
@extend sollte vermieden werden, da es ein unintuitives und potentiell gefährliches Verhalten hat, besonders wenn es mit verschachtelten Selektoren verwendet wird. Auch das Erweitern von Platzhalter-Selektoren auf oberster Ebene kann zu Problemen führen, wenn sich die Reihenfolge der Selektoren später ändert (z.B. wenn sie sich in anderen Dateien befinden und die Reihenfolge der Dateien verschoben wird). Das Gzipping sollte die meisten Einsparungen verarbeiten, die Du mit @extend erzielt hättest, und Du kannst Deine Stylesheets mit Mixins gut verbessern.
Nicht mehr als drei Ebenen tief schachteln!
.page-container {
.content {
.profile {
// STOP!
}
}
}Wenn Selektoren so lang werden, schreibst Du wahrscheinlich CSS, das:
- stark gekoppelt an das HTML (zerbrechlich) ist -ODER-
- zu spezifisch (stark) ist -ODER-
- nicht wiederverwendbar ist
Nochmals: Verschachtele niemals ID Selektoren!
Wenn Du zuerst einen ID-Selektor verwenden musst (und Du solltest wirklich versuchen, ohne auszukommen), sollten diese niemals verschachtelt werden. Wenn Du Dich dabei erwischst, musst Du Dein Markup erneut überprüfen und herausfinden, warum diese starke Spezifität erforderlich ist. Wenn Du gut geformtes HTML und CSS schreibst, solltest Du dies niemals tun müssen.
Der originale Airbnb CSS / Sass Styleguide auf Englisch ist hier abrufbar: https://github.com/airbnb/css
Dieser Styleguide ist auch in anderen Sprachen verfügbar:
Bahasa Indonesia: mazipan/css-style-guide
Chinesisch (traditionell): ArvinH/css-style-guide
Chinesisch (vereinfacht): Zhangjd/css-style-guide
Französisch: mat-u/css-style-guide
Japanisch: nao215/css-style-guide
Koreanisch: CodeMakeBros/css-style-guide
Portugiesisch (Brasilien): felipevolpatto/css-style-guide
Portugiesisch (Portugal): SandroMiguel/airbnb-css-style-guide
Russisch: Nekorsis/css-style-guide
Spanisch: ismamz/guia-de-estilo-css
Vietnamesisch: trungk18/css-style-guide
Italienisch: antoniofull/linee-guida-css
(The MIT License)
Copyright (c) 2015 Airbnb
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.