diff --git a/docs/src/config.ts b/docs/src/config.ts
index 4a8840ae5..2142fd0fc 100644
--- a/docs/src/config.ts
+++ b/docs/src/config.ts
@@ -57,7 +57,8 @@ export const SIDEBAR = {
{ text: 'Partial Hydration', link: 'de/core-concepts/component-hydration' },
{ text: 'Anleitungen', header: true },
-
+ { text: 'Styling & CSS', link: 'de/guides/styling' },
+
{ text: 'Referenz', header: true },
],
nl: [
diff --git a/docs/src/pages/de/guides/styling.md b/docs/src/pages/de/guides/styling.md
new file mode 100644
index 000000000..7273d49a2
--- /dev/null
+++ b/docs/src/pages/de/guides/styling.md
@@ -0,0 +1,645 @@
+---
+layout: ~/layouts/MainLayout.astro
+title: Styling & CSS
+description: Lerne Komponenten mit Astro zu gestalten.
+---
+
+Astro verfügt über eine besondere Möglichkeit, um das Schreiben von CSS so einfach wie möglich zu halten: Astro-Komponenten können über das Einfügen eines `
+
+Ich bin ein Style im Scope der Komponente, und ich bin rot!
+Ich bin ein Style im Scope der Komponente, und ich bin kursiv!!
+```
+
+Beachte dass der der `h1`-Selektor hier nicht über die Komponente hinaus wirksam wird! Die Styles werden nicht auf andere `h1`-Tags außerhalb dieses Dokuments angewandt - auch nicht in untergeordneten Komponenten.
+
+_Tipp: Auch wenn es möglich ist hier Element-Selektoren zu verwenden, sollten doch bevorzugt Klassen-Namen verwendet werden. Das ist nicht nur ein klein wenig performanter, es ist auch leichter zu lesen, insbesondere in einem umfangreichen Dokument._
+
+### Globale Styles
+
+Natürlich besteht die tatsächliche Macht von CSS darin, Styles so häufig wie möglich wiederzuverwenden! Die bevorzugte Methode um globale Styles einzubinden, ist die Verwendung eines `Seitentitel im Scope
+
+```
+
+_Beachte: `Astro.resolve()` ist ein nützliches Hilfsmittel, um Verweise auf Dateien von überall her aufzulösen ([docs][astro-resolve])_
+
+#### Styling untergeordneter Elemente
+
+Falls du Styles, die im Scope der Komponente gesetzt werden, auch auf untergeordnete Komponenten anwenden willst, kannst du auf die `:global()`-Funktion aus den [CSS-Modules][css-modules] zurückgreifen:
+
+```astro
+
+---
+import PostContent from './Post.astro';
+---
+
+
+Titel
+
+
+```
+
+Dies ist eine sehr gute Methode, um Dinge zu stylen wie Blogposts oder Dokumente, die mit Inhalten aus einem CMS außerhalb von Astro gefüttert werden. Aber Vorsicht, wenn untergeordnete Elemente frei von Abhängigkeiten gestaltet werden, bricht dies auch die Verkapselung der Komponente auf. Das Arbeiten mit Komponenten die unterschiedlich aussehen, abhängig davon ob sie ein bestimmtes übergeordnetes Element haben oder nicht, kann sehr schnell unübersichtlich werden.
+
+#### Globale Styles innerhalb eines `
+
+Globaler Style
+```
+
+Dasselbe kannst du erreichen, indem du einem Selektor die `:global()`-Funktion voranstellst:
+
+```html
+
+```
+
+Es wird empfohlen diese Methoden nur dort einzusetzen, wo ein `
+
+```
+
+_Beachte: Wir verwenden hier in sämtlichen Beispielen `lang="scss"`, welches das Verschachteln und Teilen von [Farben und Variablen][sass-use] stark vereinfacht. Dies ist jedoch gänzlich optional, und du kannst ebenso gut normales CSS verwenden._
+
+Die `.btn`-Klasse ist auf die Komponente begrenzt und wird nicht über das Dokument hinaus wirksam. Dies bedeutet, du kannst dich **auf das Styling und musst dich nicht auf die Benennung konzentrieren**. Dieser Ansatz, der das Lokale an den Anfang stellt, fügt sich sehr gut in das ESM-getriebene Design von Astro, das Einkapselung und Wiederverwendbarkeit über eine globale Wirksamkeit stellt. Auch wenn es sich um ein einfaches Beispiel handelt, sollte festgehalten werden, dass dies **extrem gut skaliert**. Und für den Fall, dass du gemeinsame Werte zwischen Komponenten teilen willst, empfehlen wir das [Sass-Modulsystem][sass-use], das sehr einfach zu verwenden ist und sich perfekt in ein Design einfügt, in dem die Komponente an den Anfang gestellt wird.
+
+Im Kontrast zu diesem Ansatz erlaubt Astro auch globale Styles mittels der `:global()` und `
+
+
+ Menü
+
+```
+
+Dies ist allerdings nicht erstrebenswert, da nun `` und `` bei der endgültigen Gestaltung des Buttons konkurrieren. Sobald du jetzt den einen veränderst, musst du auch den anderen anpassen, und sie sind nicht mehr wirklich isoliert, so wie zuvor (sie sind nun verbunden in bidirektionaler Abhängigkeit). Es ist sehr leicht sich vorzustellen, dass dieses Modell nur ein paar mal wiederholt werden muss, bis die Befürchtung aufkommt, dass jede Veränderung von Styles _irgendwo_ das Styling in einem ganz anderem Teil der Anwendung kaputt macht (queue `peter-griffin-css-blinds.gif`).
+
+Stattdessen kannst du `` seine eigenen Styles kontrollieren lassen und es mit einer Prop versuchen:
+
+```astro
+---
+// src/components/Button.astro
+const { theme } = Astro.props;
+---
+
+
+
+
+```
+
+An anderer Stelle kannst du nun `` verwenden, um zu bestimmen, welche Art von Button es ist. Dies bewahrt den Vertrag, in dem steht, dass _Button sich um seine Styles kümmert und Nav sich um seine_. Und nun kannst du den einen bearbeiten ohne den anderen zu beeinflussen. Der schlimmstmögliche Fall bei der Verwendung globaler Styles ist, dass eine Komponente kaputt und nicht mehr nutzbar ist (ihr fehlen wesentliche Teile ihrer Styles). Aber der schlimmstmögliche Fall bei der Verwendung von Props (z. B. bei einem Tippfehler) ist, dass die Komponente zurückgesetzt wird auf ihren ursprünglichen, aber immer noch nutzbaren, Zustand.
+
+💁 **Warum dies mit Astro gut funktioniert**. Astro ist im Wesentlichen von JavaScript-Modulen inspiriert: Du musst zu jeder Zeit nur wissen, was sich in deiner Datei befindet, und du musst dir niemals Gedanken darüber machen, welches Element aus einer anderen Datei Einfluss darauf hat, wie der Code ausgeführt wird. Aber wir sind damit nicht allein; Vue und Svelte haben beide die Idee vorangetrieben und popularisiert, dass Markup und Styles in ein und derselben Komponenten-Datei gut zusammenpassen. [Du kannst verschiedene Belange immer noch gut voneinander trennen][peace-on-css], sogar wenn Markup, Styles und Logik in einer Datei enthalten sind. Und tatsächlich ist es genau das, was Komponeten-Design so mächtig macht! Du kannst also einfach CSS schreiben ohne fürchten zu müssen, dass du einen Namen verwendest, der bereits von einer anderen Komponente in der App verwendet wird.
+
+#### Utility-CSS
+
+Vor Kurzem gab es eine Debatte über die ausschließliche Verwendung von Komponenten-Styles im Scope vs. die ausschließliche Verwendung von Utility-CSS. Aber wir stimmen Leuten wie Sarah Dayan zu, die fragen, [warum können wir nicht beides haben][utility-css]? Tatsache ist doch, dass während es großartig ist, Styles im Scope der Komponente zu haben, es immer noch hunderte von Male vorkommt, dass wenn die Website vollständig zusammengesetzt ist, zwei Elemente nicht _gut_ zusammenspielen und eines von beiden einen kleinen Stupser braucht. Oder es wird vielleicht eine abweichende Behandlung eines Textes in einer Komponenten-Instanz benötigt.
+
+Zwar ist die Vorstellung von perfekten, makellosen Komponenten schön, aber sie ist auch unrealistisch. Kein Design-System ist absolut perfekt, und jedes Design-System zeigt auch Ungereimtheiten. Und es passiert bei dem Versuch diese Ungereimtheiten aufzulösen, dass Komponenten ohne Utility-CSS durcheinander geraten. Utility-CSS ist großartig darin kleinere Optimierungen hinzuzufügen, um die Website fertigzustellen und ausliefern zu können. Aber es ist an sich auch unvollständig auf ganz eigene Art - wenn du z. B. jemals versuchst responsive Styles oder Fokussierungen mit Utility-CSS zu verwalten, kann das schnell zu einem großen Durcheinander werden!
+**Utility-CSS funktioniert am besten in Partnerschaft mit Styles im Scope der Komponente**. Und um so leicht wie möglich anwendbar zu sein, sollte Utility-CSS global sein (und sollte möglicherweise auch das einzige globale CSS sein - vielleicht neben reset.css), so dass du nicht mit Importen arbeiten musst, die allesamt willkürlich sind.
+
+Einige größere Probleme, die am besten mit Utility-CSS gelöst werden, sind:
+
+- [margin](https://github.com/drwpow/sass-utils#-margin--padding)
+- [padding](https://github.com/drwpow/sass-utils#-margin--padding)
+- [text- und background-color](https://github.com/drwpow/sass-utils#-color)
+- [font-size und font-family](https://github.com/drwpow/sass-utils#%F0%9F%85%B0%EF%B8%8F-font--text)
+- [Standardelement-Styling](https://github.com/kognise/water.css)
+
+In Astro empfehlen wir folgendes Setup hierfür:
+
+```html
+
+ ` (1), `` (2), und `` (3). Wir fügen sie wie folgt unserer Seite hinzu:
+
+```astro
+---
+// src/pages/index.astro
+
+import Nav from '../components/Nav.astro';
+import RiesenPost from '../components/RiesenPost.astro';
+import Grid from '../components/Grid.astro';
+import HalbePosts from '../components/HalberPost.astro';
+import KleinePosts from '../components/KleinerPost.astro';
+import Footer from '../components/Footer.astro';
+---
+
+
+
+
+
+
+
+
+```
+
+Das ist _anscheinend_ sauber voneinander getrennt, aber der Schein kann trügen. Auf den ersten Blick nehmen wir vielleicht an, dass `` das Layout kontrolliert, aber dieser Eindruck täuscht. Tatsächlich bestimmt `` seine Breite selbst, `` lädt zwei Komponenten und bestimmt die eigene Breite, und `` lädt vier oder mehr Komponenten und bestimmt seine eigene Breite. Insgesamt - `` eingeschlossen - streiten sich **vier Komponenten** um dasselbe Layout. Entferne einen Post von `` und das Layout zerbricht. Bearbeite ``, das Layout zerbricht. Bearbeite ``, das Layout zerbricht. Wenn du es dir genau überlegst, ist keine dieser Komponenten wirklich wiederverwendbar - sie könnten auch einfach in einer einzigen großen Datei stehen.
+
+Das ist tatsächlich das **Problem mit globalem CSS** in hübscher Verkleidung - mehrere Komponenten kämpfen darum, wie sie angeordnet werden, ohne dass es ein Layout in zentraler Verantwortung gibt (in der Art wie globales CSS)! Nun, da wir das Problem identifiziert haben, bestünde eine Möglichkeit es zu lösen darin, das gesamte Layout auf die oberste Ebene zu heben und dort ebenfalls alle Komponenten zu laden:
+
+```astro
+---
+// src/pages/index.astro
+
+import Nav from '../components/Nav.astro';
+import RiesenPost from '../components/RiesenPost.astro';
+import HalbePosts from '../components/HalberPost.astro';
+import KleinePosts from '../components/KleinerPost.astro';
+import Footer from '../components/Footer.astro';
+---
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+Wenn du dir das [CSS-Box-Model][box-model] vor Augen führst, dehnt sich darin `margin` stets über die Grenzen einer Box hinweg aus. Das bedeutet, wenn du `margin` auf das äußerste Element deiner Komponente anwendest, wird dies die Position angrenzender Komponenten beeinflussen. Selbst wenn die Styles im Scope der Komponete sind, betreffen sie _technisch_ auch Elemente um die Komponente herum - somit bricht dies mit dem [Konzept der Einschließung von Styles][layout-isolated].
+
+Wenn du Komponenten verwendest, die sich neu arrangieren oder anders dargestellt werden, sobald sie sich in der Nähe anderer Komponenten befinden, bedeutet dies einen Kampf, den du nur schwer gewinnen kannst. **Komponenten sollten sich identisch verhalten und aussehen, unabhängig davon wo sie platziert werden.** Das ist es, was sie zu Komponenten macht!
+
+💁 **Warum das in Astro gut funktioniert**: `margins` die andere Komponenten herumschubsen, unterwandern deine Styling-Architektur auf heimtückische Weise, und das kann zu wackeligen oder brüchigen Layout-Komponenten führen. Solche Dinge grundsätzlich zu vermeiden, erlaubt dir deine Layout-Komponenten einfach zu halten - und du wirst weniger Zeit mit Styling zubringen.
+
+#### Vorschlag #4: Vermeide globale Media-Queries
+
+Dieser letzte Punkt behandelt eine natürliche Beschränkung von **Styles im Scope**. Und diese bezieht sich auch auf Breakpoints! Du kennst diesen einen, seltsamen Breakpoint, bei dem deine `