Responsive Styles ohne CSS: was WordPress 7.1 im Editor kann

Bis heute gab es für «auf dem Handy bitte etwas kleiner» drei Wege: eigenes CSS, ein Zusatz-Plugin oder einen Seitenbaukasten. Mit WordPress 7.1 kommt ein vierter dazu — der Editor selbst. Tablet und Handy werden zu Zuständen, die sich direkt einstellen lassen, und zwar für praktisch jeden Block. Dazu kommen Hover, Fokus und Aktiv. Was das im Detail kann, wo die Fallstricke liegen und an welcher Stelle es mit bestehendem CSS kollidieren kann.

Was neu geht

Stile lassen sich ab 7.1 für Tablet und Handy definieren, und zwar auf zwei Ebenen: in den globalen Stilen für einen ganzen Blocktyp und zusätzlich an einer einzelnen Blockinstanz. Wer also möchte, dass alle Überschriften auf dem Handy kleiner sind, stellt das einmal global ein — und wer eine bestimmte Überschrift auf einer bestimmten Seite anders haben will, überschreibt das dort.

Die Unterstützung ist bewusst breit angelegt. Sie gilt für alle Blocktypen und deren Stilvarianten, die die Core-Unterstützungen verwenden — konkret Typografie, Farbe, Hintergrund, Rahmen, Masse, Abstände und Layout. Technisch landen die Werte unter den Schlüsseln @mobile und @tablet, entweder in der theme.json oder im bestehenden style-Attribut des Blocks:

<!-- wp:paragraph {"style":{"@mobile":{"typography":{"fontSize":"1rem"}}}} -->
<p>Text mit responsiver Schriftgrösse.</p>
<!-- /wp:paragraph -->

Die Standardgrenzen — und der fehlende Desktop

Der dritte Punkt ist der wichtigste: Es gibt keinen @desktop-Schlüssel. Der Basisstil eines Blocks ist der Desktop-Stil — und er gilt laut Dev-Note auch bei kleineren Breiten für jede Eigenschaft weiter, die nicht ausdrücklich überschrieben wurde. Wer aus anderen Werkzeugen gewohnt ist, drei Ansichten getrennt zu pflegen, muss umdenken: Sie pflegen eine Grundlage und zwei Abweichungen.

Das ist die bessere Logik, aber sie verzeiht Schludrigkeit weniger. Wenn die Grundlage nicht stimmt, korrigieren Sie den Fehler zweimal statt einmal.

Eigene Grenzen in der theme.json

782 Pixel ist keine willkürliche Zahl — es ist dieselbe Grenze, an der auch der WordPress-Adminbereich auf die schmale Ansicht wechselt. Trotzdem passt sie nicht zu jedem Entwurf. Über den neuen Schlüssel settings.viewport lassen sich beide Grenzen im Theme verschieben:

"settings": {
  "viewport": {
    "mobile": "30rem",
    "tablet": "45rem"
  }
}

Dabei gibt es drei Regeln, die man kennen muss, weil ihr Bruch keine Fehlermeldung erzeugt:

• Nur px, em und rem, und die Werte müssen nicht-negativ sein. CSS-Funktionen, Prozentwerte, einheitenlose Angaben und andere Einheiten werden ignoriert.
• Ist nur ein Wert gültig, behält er seinen Namen und wird zu einer einzelnen Maximalbreiten-Abfrage. Ist keiner gültig, greifen die Standardwerte.
• Ist der Tablet-Wert kleiner oder gleich dem Handy-Wert, wird ausschliesslich die Handy-Grenze verwendet. Das ist der naheliegende Zahlendreher — und er kostet Sie stillschweigend die Tablet-Ansicht.

Zwei Eigenschaften des Schlüssels sind leicht zu übersehen. settings.viewport ist eine Einstellung auf oberster Ebene und lässt sich nicht je Blocktyp getrennt konfigurieren. Und die konfigurierten Breiten steuern nicht nur die responsiven Stile, sondern auch die Block-Sichtbarkeit. Wer die Grenzen verschiebt, verschiebt damit zugleich, ab wann ein Block ein- oder ausgeblendet wird.

Hover, Fokus und Aktiv — ohne eine Zeile CSS

Parallel dazu wird ein zweiter Bereich geöffnet, der bisher CSS voraussetzte: die Zustände. In 7.1 lassen sich hover, focus, focus-visible und active direkt gestalten. Vorerst gilt das für zwei Blöcke — Schaltfläche und Navigationslink.

Erwähnenswert ist focus-visible: der Zustand, den ein Element bekommt, wenn es per Tastatur angesteuert wird — also genau das, worauf Menschen angewiesen sind, die eine Website ohne Maus bedienen. Dass er sich künftig ohne CSS-Kenntnisse gestalten lässt, senkt die Hürde für einen sichtbaren Fokusindikator erheblich.

Daneben führt 7.1 eigene Zustände ein, erkennbar am Präfix -. Sie sind vorerst auf die theme.json beschränkt, ohne Bedienoberfläche, und nur für den Navigationslink umgesetzt. Damit lässt sich der aktuelle Menüpunkt gestalten — jener, dessen Link auf die gerade betrachtete Seite zeigt:

"styles": {
  "blocks": {
    "core/navigation-link": {
      "-current": {
        "color": { "text": "var:preset|color|contrast" },
        ":hover": { "color": { "text": "var:preset|color|accent-1" } }
      }
    }
  }
}

Das ist praktischer, als es klingt: Der aktive Menüpunkt musste bisher über .current-menu-item im Theme-Stylesheet gestaltet werden. Pseudo-Zustände lassen sich darin verschachteln, und eigene Zustände wiederum in responsive Zustände. Was in Zukunft folgt, ist nicht der Zustand selbst, sondern die Bedienoberfläche dafür.

Wo es mit bestehendem CSS kollidieren kann

Das Update selbst ändert an bestehenden Websites nichts: Vor 7.1 konnte es keine gespeicherten responsiven Zustände geben, weil es das Merkmal nicht gab. Der Konflikt entsteht erst, wenn jemand anfängt, es zu benutzen — und dann an einer präzisen Stelle.

Laut Dev-Note erzeugt WordPress für responsive Werte eine Media-Query-gebundene CSS-Regel und hängt dem Block eine stabile, generierte Klasse an. Entscheidend ist der Nachsatz: Zustandsangaben an einer einzelnen Blockinstanz werden — ausserhalb des Layouts — mit !important ausgezeichnet, damit sie die Inline-Stile des Blocks überschreiben können. Responsive Layout-Werte und blockGap laufen dagegen über die bestehende Layout-Unterstützung.

Praktisch heisst das: Sobald jemand im Editor an einem einzelnen Block eine Handy-Schriftgrösse setzt, gewinnt diese Angabe gegen Ihr Stylesheet — auch gegen Regeln, die bisher zuverlässig gegriffen haben. Das ist kein Fehler, sondern gewollt. Es verschiebt aber, wer die Gestaltung kontrolliert, und zwar von der Datei in die Datenbank.

Deshalb eine Empfehlung, die dem Merkmal nicht widerspricht, sondern es einordnet: Gestalterische Grundentscheide gehören weiterhin in die theme.json. Die Einstellung an der einzelnen Blockinstanz ist für Ausnahmen gedacht. Wer sie zum Normalfall macht, tauscht ein Stylesheet, das in der Versionsverwaltung liegt, gegen verstreute Werte, die niemand mehr überblickt.

Häufige Fragen

Fazit

WordPress 7.1 macht aus «responsiv» eine Einstellung statt einer Programmieraufgabe. Der Gewinn liegt nicht im Tempo, sondern darin, dass Gestaltung an einem Ort liegt, den man Monate später noch versteht. Der Preis steht im Kleingedruckten: Was an der einzelnen Blockinstanz eingestellt wird, trägt !important und gewinnt gegen Ihr Stylesheet. Wer das weiss, bevor es jemand ausprobiert, spart sich die Suche danach.

Quellen

• Make WordPress Core — Responsive block styles and configurable viewports in WordPress 7.1 (5. August 2026)
• Make WordPress Core — Pseudo and custom style states in WordPress 7.1 (5. August 2026)
• Make WordPress Core — WordPress 7.1 Field Guide (5. August 2026)
• WordPress.org News — WordPress 7.1 Release Candidate 1 (5. August 2026)

Stand: 10. August 2026, geprüft gegen die Dev-Notes zum Release Candidate. WordPress 7.1 erscheint am 19. August 2026. Angaben aus Dev-Notes können sich bis dahin ändern — wir aktualisieren diesen Beitrag, wenn das geschieht.