Halte dich immer an definierte Regeln - seien es diese, oder eigene. Große oder kleine Fehler - melde dich, wenn du Unstimmigkeiten gefunden hast. Um Beiträge zu diesem Styleguide zu liefern, öffne bitte ein Issue auf GitHub.
Jede Zeile Code sollte so aussehen, als wenn sie von einer Person geschrieben wurde, egal, wieviele wirklich daran gearbeitet haben.
</li> oder </body>).<!DOCTYPE html>
<html>
<head>
<title>Seitentitel</title>
</head>
<body>
<img src="images/company-logo.png" alt="Company">
<h1 class="hello-world">Hello, world!</h1>
</body>
</html>Aktiviere den Standardmodus und konsistenteres Rendering in allen Browsern, indem der Doctype am Beginn jeder HTML Seite angegeben wird.
<!DOCTYPE html>
<html>
<head>
</head>
</html>Aus der HTML5 Spezifikation:
Autoren wird empfohlen, ein Sprachattribut im Root-HTML Tag anzugeben, um die Sprache des Dokuments bekanntzumachen. Es hilft Sprachausgabetools die richtige Aussprache zu wählen, Übersetzungstools die richtigen Regeln zu verwenden, usw.
Weitere Informationen über das lang Attribut finden sich in den Spezifikationen.
Auf Sitepoint findet sich eine Liste der Sprachcodes.
<html lang="de-de">
<!-- ... -->
</html>Der Internet Explorer unterstützt einen Kompatibilitätsmodus durch den <meta> Tag, um anzugeben, unter welcher IE Version die Seite gerendert werden soll. Sofern es andere Umstände nicht verlangen, sollte immer die modernste Version gewählt werden, indem der Edge Modus verwendet wird.
Weitere Informationen hält dieser hervorragende Stack Overflow Artikel bereit.
<meta http-equiv="X-UA-Compatible" content="IE=Edge">Das richtige Rendering des Inhalts kann schnell und einfach mit einer expliziten Zeichenkodierung festgelegt werden. Wenn die Zeichenkoderung auf diese Art gesetzt wurde, kann auf die einzelne Deklaration in HTML Elementen verzeichtet werden, sofern sie mit der des Dokumentes übereinstimmen (normalerweise UTF-8).
<head>
<meta charset="UTF-8">
</head>Nach den HTML5 Spezifikationen ist es nicht notwendig, einen type anzugeben, da CSS und JavaScript Dateien per Voreinstellung als text/css und text/javascript erwartet werden.
<!-- Externes CSS -->
<link rel="stylesheet" href="code-guide.css">
<!-- In-Dokument CSS -->
<style>
/* ... */
</style>
<!-- JavaScript -->
<script src="code-guide.js"></script>Bemühe dich, die HTML Standards und Semantik beizubehalten, aber nicht zum Preis von Praktikabilität. Benutze so wenig Markup mit den wenigsten Komplexitäten, wie möglich.
HTML Attribute sollten in der folgenden Ordnung erscheinen, um die Leserlichkeit zu erleichtern.
classid, namedata-*src, for, type, hreftitle, altaria-*, roleKlassen beinhalten wiederverwendbare Komponenten, also kommen sie zuerst. IDs sind eher spezifisch und sollten seltener verwendet werden (z.B. für seiteninterne Lesezeichen), also kommen sie als zweites.
<a class="..." id="..." data-modal="toggle" href="#">
Beispiel link
</a>
<input class="form-control" type="text">
<img src="..." alt="...">Ein boolesches Attribute braucht keinen Wert. XHTML verlangt einen gegebenen Wert, aber HTML5 benötigt es nicht.
Weitere Informationen finden sich im WhatWG Abschnitt für boolesche Attribute:
Die Anwesenheit eines booleschen Attributes an einem Element symbolisiert den Wahr-Wert, die Abwesenheit des Attributs den Falsch-Wert.
Wenn der Wert des Attributs angegeben werden muss, obwohl es eigentlich nicht notwendig ist, folge diesem WhatWG Leitsatz:
Wenn das Attribut vorhanden ist, muss sein Wert entweder ein leerer String oder [...] der kanonische Name des Attributs ohne führendes oder nachgestelltes Leerzeichen sein.
Kurzgefasst: Füge keinen Wert hinzu.
<input type="text" disabled>
<input type="checkbox" value="1" checked>
<select>
<option value="1" selected>1</option>
</select>Wenn möglich, vermeide überflüssige Elternelemente beim Schreiben von HTML. Oft sind hierfür Code-Iterationen und Refactoring notwendig, aber letzendlich wird weniger HTML produziert, wie das Beispiel zeigt:
<!-- Nicht so gut -->
<span class="avatar">
<img src="...">
</span>
<!-- Besser -->
<img class="avatar" src="...">Das Schreiben von Markup in JavaScript macht den Inhalt schwerer zu finden, schwerer zu editieren und weniger performant. Vermeide dies, wo möglich.
: für jede Deklaration hinzu.box-shadow).rgb(), rgba(), hsl(), hsla(), oder rect() Werten hinzu. Es hilft, verschiedene Farbwerte (Komma, kein Leerzeichen) von verschiedenen Eigenschaftswerten (Komma, mit Leerzeichen) zu unterscheiden..5 anstatt 0.5 und -.5px anstatt -0.5px).#fff. Kleingeschriebene Buchstaben sind beim Lesen eines Dokumentes einfacher zu unterscheiden, da sie mehr einzigartige Formen aufweisen.#fff anstatt #ffffff.input[type="text"]. Sie sind nur in einigen Fällen optional und es ist eine Gewöhnung an Konsistenz.margin: 0; anstatt margin: 0px;.Fragen bezüglich den hier verwendeten Begriffen? Weitere Informationen gibt es im Syntax Abschnitt des Cascading Style Sheet Artikels auf Wikipedia.
/* Schlechtes CSS */
.selector, .selector-secondary, .selector[type=text] {
padding:15px;
margin:0px 0px 15px;
background-color:rgba(0, 0, 0, 0.5);
box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF
}
/* Gutes CSS */
.selector,
.selector-secondary,
.selector[type="text"] {
padding: 15px;
margin-bottom: 15px;
background-color: rgba(0,0,0,.5);
box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;
}Verbundene Eigenschaftsdeklarationen sollten in der folgenden Reihenfolge gruppiert werden:
Positionierung kommt an erster Stelle, da es ein Element aus der normalen Verarbeitung eines Dokuments entfernen kann und Box Modell Styles überschreiben kann. Das Box Modell kommt als nächstes, da es die Größe und Platzierung der Komponente bestimmt.
Alles andere kommt hinterher, da es die Komponente im Inneren gestaltet, ohne die vorherigen beiden Sektionen zu beeinflussen
Eine komplette Liste der Eigenschaften und ihrer Reihenfolge kann bei Recess gefunden werden.
.declaration-order {
/* Positionierung */
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
z-index: 100;
/* Boxmodell */
display: block;
float: right;
width: 100px;
height: 100px;
/* Typographie */
font: normal 13px "Helvetica Neue", sans-serif;
line-height: 1.5;
color: #333;
text-align: center;
/* Aussehen */
background-color: #f5f5f5;
border: 1px solid #e5e5e5;
border-radius: 3px;
/* Anderes */
opacity: 1;
}@importVerglichen mit <link>s ist @import langsamer, führt zu mehr Seitenanforderungen und kann andere unvorhergesehene Probleme verursachen. Vermeide es und benutze stattdessen andere Ansätze:
<link> ElementeWeitere Informationen finden sich in einem Artikel von Steve Souders.
<!-- Verwende link-Elemente -->
<link rel="stylesheet" href="core.css">
<!-- Vermeide @imports -->
<style>
@import url("more.css");
</style>Medienabfragen sollten so nahe wie möglich an den für sie relevanten Regeln platziert werden. Bündle sie nicht alle in einem separaten Stylesheet oder am Ende des Dokuments, andernfalls ist es einfach für andere, sie in Zukunft zu übersehen. Hier ist eine typische Deklaration.
.element { ... }
.element-avatar { ... }
.element-selected { ... }
@media (min-width: 480px) {
.element { ...}
.element-avatar { ... }
.element-selected { ... }
}Wenn herstellervorbestimmte Eigenschaften verwendet werden, rücke jede Eigenschaft so ein, dass die Deklarationswerte genau untereinander stehen, damit sie einfach bearbeitet werden können.
In Textmate, drücke Text → Edit Each Line in Selection (⌃⌘A). In Sublime Text 2, drücke Selection → Add Previous Line (⌃⇧↑) und Selection → Add Next Line (⌃⇧↓).
/* Praefixeigenschaften */
.selector {
-webkit-box-shadow: 0 1px 2px rgba(0,0,0,.15);
box-shadow: 0 1px 2px rgba(0,0,0,.15);
}In Fällen, in denen ein Regelsatz nur eine einzige Deklaration enthält, sollte der Zeilenumbruch für leichtere Lesbarkeit und schnelleres Editieren entfernt werden.
Der Punkt ist hier Fehlererkennung - z.B. ein CSS Validator, der aussagt, dass ein Syntax Error in Zeile 183 vorliegt. Mit einer einzigen Deklaration kann man ihn nicht verfehlen. Bei vielen Deklarationen sind separate Zeilen ein Muss.
/* Einzelne Deklarationen in einer Zeile */
.span1 { width: 60px; }
.span2 { width: 140px; }
.span3 { width: 220px; }
/* Mehrere Deklarationen; eine pro Zeile */
.sprite {
display: inline-block;
width: 16px;
height: 15px;
background-image: url(../img/sprite.png);
}
.icon { background-position: 0 0; }
.icon-home { background-position: 0 -20px; }
.icon-account { background-position: 0 -40px; }Bemühe dich, Kurznotationen nur in den Fällen zu benutzen, wo alle verfügbaren Werte explizit gesetzt werden müssen. Übermäßig benutzte Eigenschaften sind beispielsweise:
paddingmarginfontbackgroundborderborder-radiusOft müssen nicht alle Werte gesetzt werden, die eine Kurznotation repräsentiert. Zum Beispiel setzen HTML Überschriften nur den oberen und unteren margin, also müssen nur diese beiden Werte überschrieben werden, wenn es notwendig ist. Ausschweifende Benutzung von Kurznotation in Eigenschaften führt oft zu schlampigem Code mit unnötigen Überschreibungen und ungewollten Nebeneffekten.
Im Mozilla Entwicklernetzwerk gibt es einen großartigen Artikel über Kurznotationen für Eigenschaften für diejenigen, die mit Notationen und deren Verhalten nicht vertraut sind.
/* Schlechtes Beispiel */
.element {
margin: 0 0 10px;
background: red;
background: url("image.jpg");
border-radius: 3px 3px 0 0;
}
/* Gutes Beispiel */
.element {
margin-bottom: 10px;
background-color: red;
background-image: url("image.jpg");
border-top-left-radius: 3px;
border-top-right-radius: 3px;
}Vermeide unnötige Verschachtelungen. Nur weil verschachtelt werden kann, heißt das nicht, dass man es immer sollte. Berücksichtige Verschachtelung nur, wenn Styles im Elternelement gültig sein müssen und wenn mehrere Elemente zu verschachteln sind.
// Ohne Schachtelung
.table > thead > tr > th { … }
.table > thead > tr > td { … }
// Mit Schachtelung
.table > thead > tr {
> th { … }
> td { … }
}Der Code wird von Menschen geschrieben und gepflegt. Stelle sicher, dass dein Code anschaulich, gut kommentiert und für andere zugänglich ist. Gute Kommentare vermitteln Kontext oder Zweck. Wiederhole nicht einfach den Komponenten- oder Klassennamen.
Stelle sicher, dass in längeren Kommentaren komplette Sätze geschrieben werden und kürze Sätze in generellen Anmerkungen.
/* Schlechtes Beispiel */
/* Modaler Header */
.modal-header {
...
}
/* Gutes Beispiel */
/* Umschliessendes Element fuer .modal-title und .modal-close */
.modal-header {
...
}.btn und .btn-danger)..btn ist eine nützliche Abkürzung für button, aber .s ist bedeutungslos..js-* Klassen, um Verhalten anzudeuten (im Gegensatz zu einem Style), aber halte diese Klassen aus dem CSS heraus.Außerdem ist es hilfreich, viele dieser Regeln beizubehalten, wenn Sass und Less Variablennamen erstellt werden.
/* Schlechtes Beispiel */
.t { ... }
.red { ... }
.header { ... }
/* Gutes Beispiel */
.tweet { ... }
.important { ... }
.tweet-header { ... }[class^="..."]) bei gewöhnlich verwendeten Komponenten. Es ist bekannt, dass die Browserperformance dadurch beeinträchtigt wird.Weitere informationen:
/* Schlechtes Beispiel */
span { ... }
.page-container #stream .stream-item .tweet .tweet-header .username { ... }
.avatar { ... }
/* Gutes Beispiel */
.avatar { ... }
.tweet-header .username { ... }
.tweet .avatar { ... }/*
* Komponentensektion Ueberschrift
*/
.element { ... }
/*
* Komponentensektion Überschrift
*
* Manchmal muss optionaler Kontext fuer die gesamte Komponente eingefuegt werden. Mache es so wie hier, wenn es wichtig ist.
*/
.element { ... }
/* Kontextuelle Subkomponente oder Attribut */
.element-heading { ... }Stelle deinen Editor folgendermaßen ein, um verbreitete Inkonsistenzen und dirty diffs zu vermeiden:
Ziehe in Erwägung, diese Einstellungen in die .editorconfig-Datei deines Projektes zu schreiben. Für ein Beispiel, schaue dir diese Datei in Bootstrap an. Mehr über EditorConfig erfahren.