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 (sieheOOCSS 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
- Harry Roberts' introduction to BEM
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 über den Umgang mit der Spezifität.
Vermeide die Bindung an die gleiche Klasse in Ihrem 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>Verwenden Sie 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. - Ordnen Sie Ihre 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ügen Sie Leerzeichen zwischen Ihren Regeldeklarationen und verschachtelten Selektoren sowie zwischen benachbarten verschachtelten Selektoren hinzu. Wenden Sie die gleichen Richtlinien wie oben auf Ihre verschachtelten Selektoren an.
.btn { background: green; font-weight: bold; @include transition(background 0.5s ease); .icon { margin-right: 10px; } }
Bevorzugen Sie 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 Ihren 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 beachten Sie, dass, wenn Sie Ihre 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 Sie mit @extend erzielt hätten, und Sie können Ihre Stylesheets mit Mixins gut verbessern.
Do not nest selectors more than three levels deep!
.page-container {
.content {
.profile {
// STOP!
}
}
}When selectors become this long, you're likely writing CSS that is:
- Strongly coupled to the HTML (fragile) —OR—
- Overly specific (powerful) —OR—
- Not reusable
Again: never nest ID selectors!
If you must use an ID selector in the first place (and you should really try not to), they should never be nested. If you find yourself doing this, you need to revisit your markup, or figure out why such strong specificity is needed. If you are writing well formed HTML and CSS, you should never need to do this.
This style guide is also available in other languages:
Bahasa Indonesia: mazipan/css-style-guide
Chinese (Traditional): ArvinH/css-style-guide
Chinese (Simplified): Zhangjd/css-style-guide
French: mat-u/css-style-guide
Japanese: nao215/css-style-guide
Korean: CodeMakeBros/css-style-guide
Portuguese (Brazil): felipevolpatto/css-style-guide
Portuguese (Portugal): SandroMiguel/airbnb-css-style-guide
Russian: Nekorsis/css-style-guide
Spanish: ismamz/guia-de-estilo-css
Vietnamese: trungk18/css-style-guide
Italian: 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.