Die Art und Weise, wie wir CSS für WordPress-Themes schreiben, befindet sich mitten in weitreichenden Änderungen. Ich habe kürzlich eine Technik für geteilt Hinzufügen von Unterstützung für flüssige Typen in WordPress durch theme.json, eine neue Datei, die WordPress hat hart Druck gemacht eine zentrale Quelle der Wahrheit für die Definition von Stilen in WordPress-Designs zu werden, die Full-Site-Editing (FSE)-Funktionen unterstützen.

Warte, nein style.css Datei? Das haben wir noch. In der Tat, style.css is immer noch eine erforderliche Datei in Blockthemen, obwohl seine Rolle stark auf Metainformationen reduziert ist, die zum Registrieren des Themas verwendet werden. Das heißt, Tatsache ist, dass theme.json befindet sich noch in der aktiven Entwicklung, was bedeutet, dass wir uns in einer Übergangsphase befinden, in der Sie möglicherweise Stile finden, die dort definiert sind styles.css oder sogar auf Blockebene.

Also, wie sieht das Styling in diesen WordPress-FSE-Tagen eigentlich aus? Darauf möchte ich in diesem Artikel eingehen. Es fehlt an Dokumentation zum Stylen von Blockdesigns in der Entwicklerhandbuch für WordPress-Themes, also alles, was wir hier behandeln, ist das, was ich über den aktuellen Stand der Dinge sowie Diskussionen über die Zukunft des WordPress-Themes gesammelt habe.

Die Evolution der WordPress-Stile

Die neuen Entwicklungsfunktionen, die in enthalten sind WordPress 6.1 bringen uns einem System von Stilen näher, die vollständig in definiert sind theme.json, aber es gibt noch viel zu tun, bevor wir uns voll darauf stützen können. Eine Möglichkeit, sich ein Bild davon zu machen, was in zukünftigen Versionen auf uns zukommt, ist die Verwendung von Gutenberg-Plugin. Hier werden experimentelle Features oft auf die Probe gestellt.

Eine andere Möglichkeit, ein Gefühl dafür zu bekommen, wo wir uns befinden, besteht darin, die Entwicklung von zu betrachten Standard-WordPress-Themes. Bis heute gibt es drei Standarddesigns, die die vollständige Bearbeitung der Website unterstützen:

Aber fangen Sie nicht an, das CSS einzutauschen style.css für JSON-Eigenschaft/Wert-Paare in theme.json Jetzt. Es gibt immer noch CSS-Stilregeln, die unterstützt werden müssen theme.json bevor wir darüber nachdenken. Die verbleibenden wichtigen Probleme werden derzeit mit dem Ziel diskutiert, alle CSS-Stilregeln vollständig einzuführen theme.json und konsolidieren verschiedene Quellen von theme.json in ein Benutzeroberfläche zum Festlegen globaler Stile direkt in der WordPress-Site-Editor.

Das bringt uns in eine relativ schwierige Lage. Es gibt nicht nur kein klarer Pfad zum Überschreiben von Themenstilen, aber es ist unklar, woher die Quelle dieser Stile überhaupt kommt – stammen sie aus verschiedenen Schichten von theme.json Dateien, style.css, das Gutenberg-Plugin oder woanders?

Warum theme.json statt style.css?

Du fragst dich vielleicht, warum WordPress zu einer JSON-basierten Definition von Stilen statt zu einer traditionellen CSS-Datei übergeht. Ben Dwyer vom Gutenberg-Entwicklungsteam artikuliert eloquent, warum die theme.json Ansatz ist ein Vorteil für Theme-Entwickler.

Es lohnt sich, Bens Beitrag zu lesen, aber das Fleisch steckt in diesem Zitat:

Das Überschreiben von CSS, ob Layout, Voreinstellung oder Blockstile, stellt ein Hindernis für die Integration und Interoperabilität dar: Die visuelle Parität zwischen Frontend und Editor wird schwieriger aufrechtzuerhalten, Upgrades auf Blockinterna können mit Überschreibungen in Konflikt geraten. Benutzerdefiniertes CSS ist außerdem weniger übertragbar auf andere Blockthemen.

Indem Themenautoren zur Verwendung ermutigt werden theme.json API wo möglich, kann die Hierarchie von „Basis > Thema > Benutzer“ definierten Stilen korrekt aufgelöst werden.

Einer der Hauptvorteile der Umstellung von CSS auf JSON besteht darin, dass JSON ein maschinenlesbares Format ist, was bedeutet, dass es in der Benutzeroberfläche des WordPress-Site-Editors durch Abrufen einer API verfügbar gemacht werden kann, sodass Benutzer Standardwerte ändern und das Erscheinungsbild einer Website anpassen können ohne überhaupt CSS schreiben. Es bietet auch eine Möglichkeit, Blöcke konsistent zu gestalten, während es eine Struktur bereitstellt, die Ebenen der Spezifität schafft, sodass die Benutzereinstellungen die höchste Priorität gegenüber den in definierten haben theme.json. Dieses Zusammenspiel zwischen Stilen auf Themenebene in theme.json und die benutzerdefinierten Stile in der Global Styles-Benutzeroberfläche machen den JSON-Ansatz so attraktiv.

Entwickler behalten die Konsistenz in JSON bei, und Benutzer gewinnen durch Anpassungen ohne Code an Flexibilität. Das ist eine Win-Win-Situation.

Es gibt sicher andere Vorteile, und Mike McAlister von WP Engine listet mehrere in diesem Twitter-Thread auf. Darin können Sie noch mehr Vorteile finden ausführliche Diskussion drüben im Make WordPress Core-Blog. Und wenn Sie sich das einmal durchgelesen haben, vergleichen Sie die Vorteile des JSON-Ansatzes mit die verfügbaren Möglichkeiten zum Definieren und Überschreiben von Stilen in klassischen Themen.

Stile mit JSON-Elementen definieren

Wir haben bereits viele Fortschritte in Bezug auf die Teile eines Themas gesehen theme.json kann stylen. Vor WordPress 6.1 konnten wir eigentlich nur Überschriften und Links gestalten. Jetzt, mit WordPress 6.1, Wir können Schaltflächen, Beschriftungen, Zitate und Überschriften hinzufügen zur Mischung.

Und das tun wir, indem wir definieren JSON-Elemente. Stellen Sie sich Elemente als einzelne Komponenten vor, die in einem WordPress-Block leben. Angenommen, wir haben einen Block, der eine Überschrift, einen Absatz und eine Schaltfläche enthält. Diese einzelnen Stücke sind Elemente, und es gibt eine elements Objekt in theme.json wo wir ihre Stile definieren:

{
  "version": 2,
  "settings": {},
  // etc.
  "styles": {
    // etc.
    "elements": {
        "button": { ... },
        "h1": { ... },
        "heading": { ... },
    },
  },
  "templateParts": {}
}

Eine bessere Möglichkeit, JSON-Elemente zu beschreiben, sind Low-Level-Komponenten für Designs und Blöcke, die nicht die Komplexität von Blöcken benötigen. Sie sind Darstellungen von HTML-Primitiven die nicht in einem Block definiert sind, aber blockübergreifend verwendet werden können. Wie sie in WordPress (und dem Gutenberg-Plugin) unterstützt werden, ist im beschrieben Block-Editor-Handbuch und dies Vollständiges Tutorial zur Website-Bearbeitung von Carolina Nymark.

Beispielsweise werden Links in der formatiert elements Objekt, sind aber kein eigener Block. Ein Link kann jedoch in einem Block verwendet werden und er erbt die auf dem definierten Stile elements.link Objekt in theme.json. Dies kapselt die Definition eines Elements jedoch nicht vollständig ein, da einige Elemente auch als Blöcke registriert sind, z. B. die Heading- und Button-Blöcke – diese Blöcke können jedoch weiterhin in anderen Blöcken verwendet werden.

Hier ist eine Tabelle der Elemente, die derzeit zum Stylen verfügbar sind theme.json, Mit freundlicher Genehmigung von Carolina:

Wie Sie sehen können, ist es noch früh und es muss noch viel vom Gutenberg-Plugin in WordPress Core verschoben werden. Aber Sie können sehen, wie schnell es wäre, so etwas wie alle Überschriften in einem Design global zu formatieren, ohne in CSS-Dateien oder DevTools nach Selektoren suchen zu müssen.

Außerdem können Sie auch beginnen zu sehen, wie die Struktur von theme.json Art von Schichten der Spezifität, ausgehend von globalen Elementen (z headings) zu einzelnen Elementen (z h1) und Stile auf Blockebene (z h1 in einem Block enthalten).

Weitere Informationen zu JSON-Elementen finden Sie unter diesen WordPress-Vorschlag machen und dieses offene Ticket im GitHub-Repo des Gutenberg-Plugins.

JSON- und CSS-Spezifität

Reden wir weiter über die CSS-Spezifität. Ich habe bereits erwähnt, dass der JSON-Ansatz für das Styling eine Hierarchie einrichtet. Und es ist wahr. Stile, die für JSON-Elemente in definiert sind theme.json gelten als Standarddesignstile. Und alles, was vom Benutzer in der Benutzeroberfläche für globale Stile festgelegt wird, überschreibt die Standardeinstellungen.

Mit anderen Worten: Benutzerstile sind spezifischer als Standarddesignstile. Werfen wir einen Blick auf den Button-Block, um ein Gefühl dafür zu bekommen, wie das funktioniert.

Ich benutze Leeres Thema, ein leeres WordPress-Theme ohne CSS-Stil. Ich werde einen Button-Block auf einer neuen Seite hinzufügen.

OK, wir wissen, dass WordPress Core mit leichtem Styling ausgeliefert wird. Jetzt werde ich zum Standard-TT3-Theme von WordPress 6.1 wechseln und es aktivieren. Wenn ich meine Seite mit der Schaltfläche aktualisiere, ändert die Schaltfläche den Stil.

Sie können genau sehen wo diese neuen Stile herkommen bei TT3 theme.json Datei. Dies sagt uns, dass die JSON-Elementstile Vorrang vor den WordPress-Core-Stilen haben.

Jetzt werde ich TT3 ändern, indem ich es mit a überschreibe theme.json Datei in einem Child-Theme, wobei die Standard-Hintergrundfarbe des Button-Blocks auf Rot eingestellt ist.

Beachten Sie jedoch die Suchschaltfläche in diesem letzten Screenshot. Rot sollte es auch sein, oder? Das muss bedeuten, dass es auf einer anderen Ebene gestaltet ist, wenn die von mir vorgenommene Änderung auf globaler Ebene erfolgt. Wenn wir uns ändern wollen beide Schaltflächen, könnten wir dies auf Benutzerebene tun, indem wir die Global Styles-Benutzeroberfläche im Site-Editor verwenden.

Wir haben die Hintergrundfarbe beider Schaltflächen in Blau geändert und auch den Text mithilfe der Benutzeroberfläche für globale Stile geändert. Beachten Sie, dass das Blau von dort Vorrang vor den Themenstilen hatte!

Die Style-Engine

Das ist eine sehr schnelle, aber gute Vorstellung davon, wie CSS-Spezifität in WordPress-Blockdesigns verwaltet wird. Aber es ist nicht das vollständige Bild, weil es noch unklar ist woher diese Stile werden generiert. WordPress hat seine eigenen Standardstile, die irgendwo herkommen und die Daten verbrauchen theme.json für weitere Stilregeln und überschreibt diese mit allen Einstellungen in Global Styles.

Sind diese Stile inline? Sind sie in einem separaten Stylesheet? Vielleicht sind sie auf der Seite in einen gespritzt ?

Das ist das Neue Style-Engine wird sich hoffentlich lösen. Die Style Engine ist eine neue API in WordPress 6.1, die dafür sorgen soll, wie Styles generiert und wo Styles angewendet werden. Mit anderen Worten, es nimmt alle möglichen Stilquellen und ist allein dafür verantwortlich, Blockstile richtig zu erzeugen. Ich weiß, ich weiß. Noch eine weitere Abstraktion auf anderen Abstraktionen, nur um einige Stile zu schreiben. Aber eine zentralisierte API für Stile zu haben, ist wahrscheinlich die eleganteste Lösung, da Stile von verschiedenen Orten stammen können.

Wir bekommen nur einen ersten Blick auf die Style Engine. Tatsächlich wurde Folgendes bisher fertiggestellt: laut Fahrkarte:

• Prüfen und konsolidieren Sie, wo der Code Blockunterstützungs-CSS im Back-End generiert, sodass sie von derselben Stelle (im Gegensatz zu mehreren Stellen) bereitgestellt werden. Dies umfasst CSS-Regeln wie Rand, Polsterung, Typografie, Farben und Rahmen.
• Entfernen Sie sich wiederholende Layout-spezifische Stile und generieren Sie semantische Klassennamen.
• Reduzieren Sie die Anzahl der Inline-Stil-Tags, die wir zur Unterstützung von Blöcken, Layouts und Elementen auf die Seite drucken.

Im Grunde ist dies die Grundlage für die Einrichtung einer einzigen API, die alle CSS-Stilregeln für ein Thema enthält, woher sie auch immer kommen. Es bereinigt die Art und Weise, wie WordPress Inline-Stile vor 6.1 einfügt, und etabliert ein System für semantische Klassennamen.

Weitere Details zu den langfristigen und kurzfristigen Zielen von Style Engine finden Sie hier Führen Sie eine WordPress Core-Diskussion. Sie können auch folgen Tracking-Problem und Projektboard für weitere Updates.

Arbeiten mit JSON-Elementen

Wir haben ein wenig über JSON-Elemente in der gesprochen theme.json Datei und wie sie im Grunde HTML-Primitive sind, um unter anderem Standardstile für Dinge wie Überschriften, Schaltflächen und Links zu definieren. Nun, schauen wir uns das eigentlich an Verwendung von ein JSON-Element und wie es sich in verschiedenen Styling-Kontexten verhält.

JSON-Elemente haben im Allgemeinen zwei Kontexte: die Globale Ebene und für Blockebene. Die Stile auf globaler Ebene werden mit weniger Spezifität definiert als auf Blockebene, um sicherzustellen, dass blockspezifische Stile aus Gründen der Einheitlichkeit Vorrang haben, wo immer Blöcke verwendet werden.

Globale Stile für JSON-Elemente

Schauen wir uns das neue Standard-TT3-Design an und untersuchen, wie seine Schaltflächen gestaltet sind. Das Folgende ist ein abgekürztes Kopieren und Einfügen des TT3 theme.json Datei (hier ist die vollständiger Code) mit dem Abschnitt „Globale Stile“, aber den Originalcode finden Sie hier.

{
  "version": 2,
  "settings": {},
    // ...
  "styles": {
    // ...
    "elements": {
      "button": {
        "border": {
          "radius": "0"
        },
        "color": {
          "background": "var(--wp--preset--color--primary)",
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":focus": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":active": {
          "color": {
            "background": "var(--wp--preset--color--secondary)",
            "text": "var(--wp--preset--color--base)"
          }
        }
      },
      "h1": {
        "typography": { }
      },
      // ...
      "heading": {
        "typography": {
          "fontWeight": "400",
          "lineHeight": "1.4"
      }
      },
      "link": {
        "color": {
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "typography": {
            "textDecoration": "none"
          }
        },
        ":focus": {
          "typography": {
            "textDecoration": "underline dashed"
          }
        },
        ":active": {
          "color": {
            "text": "var(--wp--preset--color--secondary)"
          },
          "typography": {
            "textDecoration": "none"
          }
        },
        "typography": {
          "textDecoration": "underline"
        }
      }
     },
    // ...
  },
  "templateParts": {}
}

Alle Schaltflächen sind auf globaler Ebene gestaltet (styles.elements.button).

Wir können dies auch in DevTools bestätigen. Beachten Sie, dass eine Klasse aufgerufen hat .wp-element-button ist der Selektor. Dieselbe Klasse wird auch zum Gestalten der interaktiven Zustände verwendet.

Auch dieses Styling findet auf globaler Ebene statt theme.json. Immer wenn wir eine Schaltfläche verwenden, hat sie denselben Hintergrund, da sie denselben Selektor teilen und keine anderen Stilregeln ihn überschreiben.

Nebenbei wurde WordPress 6.1 hinzugefügt Unterstützung für das Gestalten interaktiver Zustände für bestimmte Elemente, wie Schaltflächen und Links, die Verwendung von Pseudo-Klassen in theme.json - einschließlich :hover, :focus und :active — oder die Benutzeroberfläche für globale Stile. Automatik-Ingenieur Dave Smith zeigt Dieses Feature in einem YouTube-Video.

Wir könnten die Hintergrundfarbe der Schaltfläche entweder in überschreiben theme.json (vorzugsweise in einem untergeordneten Design, da wir ein standardmäßiges WordPress-Design verwenden) oder in den Einstellungen für globale Stile im Website-Editor (kein untergeordnetes Design erforderlich, da keine Codeänderung erforderlich ist).

Aber dann ändern sich die Tasten auf einmal. Was ist, wenn wir die Hintergrundfarbe überschreiben möchten, wenn die Schaltfläche Teil eines bestimmten Blocks ist? Hier kommen Stile auf Blockebene ins Spiel.

Stile auf Blockebene für Elemente

Um zu verstehen, wie wir Stile auf Blockebene verwenden und anpassen können, ändern wir die Hintergrundfarbe der Schaltfläche, die im Suchblock enthalten ist. Denken Sie daran, dass es einen Schaltflächenblock gibt, aber wir überschreiben die Hintergrundfarbe auf der Blockebene des Suchblocks. Auf diese Weise wenden wir die neue Farbe nur dort an, anstatt sie global auf alle Schaltflächen anzuwenden.

Dazu definieren wir die Stile auf der styles.blocks Objekt in theme.json. Richtig, wenn wir die globalen Styles für alle Buttons weiter definieren styles.elements, können wir die blockspezifischen Stile für Schaltflächenelemente definieren styles.block, die einer ähnlichen Struktur folgt:

{
  "version": 2,
  // ...
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": {
      "core/search": {
        "elements": {
          "button": {
            "color": {
              "background": "var(--wp--preset--color--quaternary)",
              "text": "var(--wp--preset--color--base)"
            }
          }
        },
        // ...
      }
    }
  }
}

Siehst du das? Ich setze die background und text Eigenschaften auf styles.blocks.core/search.elements.button mit zwei CSS-Variablen, die in WordPress voreingestellt sind.

Das Ergebnis? Die Suchschaltfläche ist jetzt rot (--wp--preset--color--quaternary), und der standardmäßige Button-Block behält seinen hellgrünen Hintergrund.

Wir können die Änderung auch in DevTools sehen.

Das Gleiche gilt, wenn wir Schaltflächen gestalten möchten, die in anderen Blöcken enthalten sind. Und Schaltflächen sind nur ein Beispiel, also schauen wir uns ein anderes an.

Beispiel: Überschriften auf jeder Ebene gestalten

Lassen Sie uns all diese Informationen anhand eines Beispiels nach Hause bringen. Diesmal werden wir:

• Gestalten Sie alle Überschriften global
• Gestalten Sie alle Elemente von Überschrift 2
• Style Heading 2-Elemente im Query Loop-Block

Beginnen wir zunächst mit der Grundstruktur für theme.json:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": { }
  }
}

Dies legt den Rahmen für unsere globalen Stile und Stile auf Blockebene fest.

Gestalten Sie alle Überschriften global

Fügen wir das hinzu headings widersprechen Sie unseren globalen Stilen und wenden Sie einige Stile an:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
    },
    // Block-level styles
    "blocks": { }
  }
}

Das setzt die Farbe für alle Überschriften auf die voreingestellte Grundfarbe in WordPress. Lassen Sie uns die Farbe und Schriftgröße der Elemente von Überschrift 2 auch auf globaler Ebene ändern:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": { }
  }
}

Jetzt werden alle Elemente der Überschrift 2 mit a auf die primäre voreingestellte Farbe gesetzt flüssige Schriftgröße. Aber vielleicht wollen wir eine feste fontSize für das Element „Überschrift 2“, wenn es im Block „Abfragesuche“ verwendet wird:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": {
      "core/query": {
        "elements": {
          "h2": {
            "typography": {
              "fontSize": 3.25rem
            }
          }
        }
      }
    }
  }
}

Jetzt haben wir drei Ebenen von Stilen für Überschrift 2-Elemente: alle Überschriften, alle Überschrift 2-Elemente und Überschrift 2-Elemente, die im Abfrageschleifenblock verwendet werden.

Bestehende Themenbeispiele

Während wir uns in diesem Artikel nur die Styling-Beispiele für Schaltflächen und Überschriften angesehen haben, unterstützt WordPress 6.1 das Styling zusätzlicher Elemente. Es gibt eine Tabelle, in der sie skizziert werden „Stile mit JSON-Elementen definieren“ .

Sie fragen sich wahrscheinlich, welche JSON-Elemente welche CSS-Eigenschaften unterstützen, ganz zu schweigen davon, wie Sie diese überhaupt deklarieren würden. Während wir auf die offizielle Dokumentation warten, sind die besten Ressourcen, die wir haben, die theme.json Dateien für vorhandene Themen. Ich werde Links zu Themen bereitstellen, die auf den Elementen basieren, die sie anpassen, und darauf hinweisen, welche Eigenschaften angepasst werden.

Achten Sie darauf, jeden zu geben theme.json Datei einen guten Blick, denn diese Themen enthalten hervorragende Beispiele für Block-Level-Styling auf der styles.blocks Objekt.

Wrapping up

Häufige Änderungen am Full-Site-Editor werden zu einer für viele Menschen eine große Irritationsquelleeinschließlich technisch versierte Gutenberg-Benutzer. Selbst sehr einfache CSS-Regeln, die gut mit klassischen Themes funktionieren, scheinen wegen der nicht für Block-Themes zu funktionieren neue Ebenen der Spezifität wir haben früher abgedeckt.

In Bezug auf a GitHub-Vorschlag den Seiteneditor in einem neuen Browsermodus neu zu gestalten, Sara Gooding schreibt in einem Beitrag von WP Tavern:

Es ist leicht, sich zu verirren, wenn man versucht, den Site-Editor zu umgehen, es sei denn, man arbeitet Tag und Nacht im Tool. Die Navigation ist sprunghaft und verwirrend, insbesondere wenn Sie vom Durchsuchen der Vorlagen über die Bearbeitung der Vorlagen bis hin zum Ändern einzelner Blöcke wechseln.

Selbst als begeisterter Early Rider in der Welt des Gutenberg-Block-Editors und der Block-Eye-Themen habe ich jede Menge meiner eigenen Frustrationen. Ich bin jedoch optimistisch und gehe davon aus, dass der Website-Editor nach seiner Fertigstellung ein revolutionäres Werkzeug für Benutzer und technisch versierte Themenentwickler gleichermaßen sein wird. Dies hoffnungsvoller Tweet bestätigt das schon. In der Zwischenzeit scheinen wir uns auf weitere Änderungen und vielleicht sogar auf eine holprige Fahrt vorbereiten zu müssen.

Bibliographie

Ich liste alle Ressourcen auf, die ich bei der Recherche von Informationen für diesen Artikel verwendet habe.

JSON-Elemente

Globale Stile

Style-Engine

Danke fürs Lesen! Ich würde gerne Ihre eigenen Überlegungen zur Verwendung der Blockdesigns und zur Verwaltung Ihres CSS hören.